L’approche SdS (voir encadré) consiste à considérer un ensemble de systèmes déployés comme un système unique plutôt que d’étudier chaque système isolément. Cette approche seule permet de :

• concevoir des fonctionnements complexes traversant jusqu’à 15 interfaces techniques dans leur déroulement, et néanmoins fluides et efficaces ;
• rechercher des optima globaux sur la constitution des parcs de matériels ou sur le choix de responsabiliser tel système sur telle performance.

Cet angle d’attaque confronte le concepteur du SdS à un objet d’étude difficile à appréhender du fait de la combinatoire très importante de GTIA possibles, en nombre (jusqu’à 400 véhicules), en variété, en variabilité (liée aux équipements optionnels notamment) et en mobilité de ses éléments constitutifs.

Ces éléments ont conduit le programme Scorpion à s’investir dans les meilleures pratiques d’ingénierie système, aussi bien au niveau du SdS qu’à celui de ses opérations constituantes : véhicules Griffon, Jaguar, Leclerc rénové et VBMR léger, système d’information SICS et Système de Préparation Opérationnelle. Au-delà, ils l’ont poussé à adapter en profondeur le triptyque « processus – méthodes – outils » de l’ingénierie système quand il ne répondait pas aux spécificités du SdS. En effet, la plupart des passages obligés habituels au niveau système, tels la gestion de configuration, la formation et la testabilité, trouvent leur analogie au niveau SdS et doivent être traités à ce niveau, mais avec bien souvent des particularités non couvertes par l’état de l’art.

Des avancées méthodologiques

« Casser les silos »

La conception des fonctionnements collaboratifs Scorpion s’organise selon un axe orthogonal aux silos des opérations d’armement pour internaliser des séries d’interfaces habituellement négociées au mieux deux à deux : les chaînes fonctionnelles de bout en bout. Le périmètre d’une chaîne fonctionnelle doit contenir l’intégralité des fonctions s’enchaînant pour réaliser la capacité et être pilotable par un responsable unique. L’analyse fonctionnelle du SdS Scorpion a permis d’isoler 13 chaînes fonctionnelles essentiellement conformes à ces critères. Citons la « Tenue de situation AMI » pour le suivi et le partage des positions et états des éléments alliés, la « Protection collaborative » pour l’accélération de la riposte coordonnée face à une agression soudaine, ou encore la chaîne « Renseignement ». En dépit de cet effort, les périmètres retenus font apparaître des interfaces résiduelles entre chaînes que la modélisation d’architectures permet de gérer.

« S’abstraire de la combinatoire »

Concrètement, l’étude du SdS Scorpion doit permettre de définir les spécifications à imposer aux différents systèmes et d’expliquer aux forces quelles compositions de GTIA sont conformes aux contraintes techniques imposées par le niveau de performance recherché. Concevoir et exprimer l’allocation des fonctions en considérant individuellement chaque véhicule dans chacune de ses configurations est à proscrire, qualifier et décrire chaque composition possible une à une encore plus : la combinatoire est trop élevée. De plus, une majorité d’informations et d’exigences est en fait commune à plusieurs systèmes. Remonter d’un niveau en abstraction, manipuler des classes d’objets plutôt que les objets eux-mêmes est donc à la fois nécessaire et possible. Cette abstraction permet des synthèses et crée des points focaux pour un grand nombre d’échanges : de l’architecture SdS vers la spécification des systèmes, des concepteurs de la DGA vers les forces utilisatrices, des concepteurs du SdS vers ceux qui en suivront la configuration en aval. Trois notions se dégagent :

• la notion amirale est celle des « Articles de Configuration Scorpion » ou ACS : ce sont des classes de systèmes définies par la fonction principale qui leur est allouée. Citons les systèmes d’information et de combat socles (SICS et Atlas par exemple), les radios (PR4G, Contact, RIF, etc.), les organes de géolocalisation (GPS, centrale inertielle, etc.), les grands types de véhicules porteurs, les modules de protection collaborative ;
• les fonctions allouées à ces ACS sont explicitées par des exigences qui devront être tenues par les systèmes candidats à répondre à l’ACS : les « labels ». Ceux-ci sont imposés aux systèmes par le SdS à travers les outils habituels de suivi d’interface, mais celle-ci s’avère verticale (du SdS vers le système) plutôt qu’horizontale (entre systèmes) ;
• enfin, les contraintes techniques à respecter par les forces lors de la composition d’un GTIA, qui portent généralement sur des volumes absolus ou relatifs des différents ACS, sont appelées « règles de composition ».

Ces trois éléments constituent l’essentiel de la définition du SdS Scorpion et représentent un volume de données inférieur d’un facteur 10 voire 100 aux descriptions exhaustives des objets manipulés tels que les compositions de GTIA.

« Qualifier l’intangible »

Le SdS n’ajoute pas de système aux systèmes et on pourrait en conclure qu’il n’a pas d’existence tangible : « Personne ne s’est jamais coincé le doigt dans un système de systèmes » entend-on parfois ! Pourtant les fonctionnements collaboratifs sont bien réels et subissent des risques spécifiques qui ne sont couverts par aucune opération individuellement. Parmi la douzaine de risques identifiés sur la base du retour d’expérience des essais du programme d’études amont Bulle Opérationnelle Aéroterrestre, précurseur de Scorpion, citons par exemple le passage à l’échelle et l’émergence des comportements qui sont des caractéristiques propres des SdS. De ce fait, une stratégie de qualification a été construite au niveau SdS qui exploite le résultat des qualifications menées sur les systèmes (vérification des labels) mais aussi des moyens adaptés à ces risques. Parmi les moyens d’essais, citons des moyens de simulation, les bancs hybride de DGA Techniques Terrestres (quelques véhicules réels plongés dans un GTIA simulé) et SIO COM² de DGA Maîtrise de l’Information (plusieurs systèmes d’information et radios mis en relation dans un environnement simulé), et la Force d’Expertise du Combat Scorpion qui réalisera en commun essais terminaux de la DGA et évaluation voire entraînement des forces, sur le terrain.

Les essais SdS permettent de qualifier chaque incrément capacitaire du programme (les Niveaux Capacitaires Scorpion) en même temps que le premier GTIA obtenant la performance correspondante, puis de valider la non régression des fonctions collaboratives lors de l’introduction de systèmes constituants nouveaux ou modifiés, dans le cadre d’un cycle annuel dit de « labellisation » de ces systèmes : ces résultats autorisent formellement la constitution de GTIA opérationnels embarquant les systèmes labellisés. Suffisamment dense pour éviter un saut technologique trop important entre deux évaluations, ce cycle annuel libère la contrainte entre calendrier du SdS et calendriers des systèmes : il suffit que le système soit qualifié assez tôt dans le cycle pour intégrer la campagne SdS suivante.

En outre, afin de rester compatible des capacités d’essai accessibles malgré la combinatoire, une optimisation est nécessaire et passe, d’une part, par des compétences de construction de plans d’expérience, d’autre part, par une capacité de jouer des scénarios très nombreux en peu de temps pour trouver les nœuds fonctionnels à explorer en essais réels, ce qui impose de sortir l’homme de la boucle et donc de développer des outils de simulation très autonomes.

Une riche palette d’outils

« Sortir de la tour d’ivoire »

La couche SdS confronte l’équipe à un volume très important d’interfaces et produit des fonctionnements collaboratifs extrêmement imbriqués. Il n’est pas question pour autant de se réfugier derrière une architecture théorique parfaite exprimée sur des notions abstraites mais qu’aucun système réel ne permettrait de mettre en œuvre. Il y a donc un caractère itératif et incrémental fort à la fois en conception et en suivi en service du SdS Scorpion pour prendre en compte la réalité des systèmes. Ces échanges, très riches, nécessitent des outils nativement adaptés à la gestion des liens entre données, à la traçabilité des impacts et des décisions, et à la rédaction collaborative. La spécification de Scorpion est ainsi réalisée sous DOORS³ et trace la satisfaction des besoins de leur expression par les opérationnels jusqu’à la spécification des opérations constituantes. Nous partageons de plus nos données dans deux portails outillés, IsiCO et B@RTOC^©, auxquels ont accès les opérationnels. Ces portails ont vocation à évoluer en intégrant de nouvelles fonctionnalités, telles que l’aide à la génération de forces qui doit accompagner l’armée de Terre sur l’application des règles de composition technique des GTIA.

« Représenter la complexité »

Dans sa position particulière de maître d’œuvre du SdS Scorpion, la DGA utilise deux outils principaux pour le spécifier, le concevoir et le représenter : Sispeo⁴ (voir encadré) pour l’échange concret avec les opérationnels et MEGA for NAF¹ pour représenter les fonctionnements attendus sous forme de schémas et en extraire par requête les synthèses nécessaires aux divers échanges d’informations, entre pilotes (interface inter-chaînes), avec les opérations constituantes (labels) ou avec les opérationnels (justification de la prise en compte du besoin). L’analyse des chaînes fonctionnelles Scorpion devrait même conduire à faire évoluer MEGA for NAF, afin de gérer des variantes d’architecture par exemple.

Demain, Scorpion élargira son périmètre en intégrant, entre autres, les appuis et la robotique aéroterrestre. Il visera des optimisations permanentes et encore plus précises grâce à de nouveaux outils comme la recherche opérationnelle. Son défi premier, aujourd’hui, et le nœud de son succès, est l’adhésion et l’envie de ses contributeurs et utilisateurs, dans un cadre qui se caractérise justement par l’indépendance managériale et opérationnelle des systèmes constituants. Scorpion doit convaincre d’emblée pour obtenir cet effet d’entraînement. Une conception pertinente et des démonstrations initiales convaincantes sont de ce fait le camp de base incontournable d’une longue ascension qui mène au maintien à long terme de la supériorité des soldats que la France envoie au contact direct de ses adversaires : cela vaut bien, sans doute, l’investissement intellectuel et méthodologique qu’y consacre la DGA !

1) Mega est la solution logicielle retenue par la DGA pour représenter sous forme de diagrammes les architectures des Sds.
NAF : Nato Architecture Framework.
2) SIO COM : système d’information opérationnel de commandement.
3) DOORS, Dynamic Object-Oriented Requirements System, système de gestion des exigences.
4) SISPEO : Simulateur d’Interfaces hommes-machines SPécialisé dans les études d’Organisation.

Pierre-Marie Lecat, IPA, Architecte de cohérence technique (ACT) SCORPION Après deux années dans le secteur privé, Pierre-Marie Lecat (Centrale 2001, Air et espace) intègre la DGA en 2004. D’abord directeur d’essai à Saclay, il devient architecte sur M51 puis M2000. Il est architecte de cohérence technique du programme Scorpion depuis 2014.

Delphine Dufourd-Moretti, ICA, Manager SCORPION Après avoir exercé des fonctions d’architecte et d’encadrement technique en robotique et en systèmes terrestres à la DGA, Delphine Dufourd-Moretti (X95, ENSTA, doctorat INPT) est depuis 2013 manager Scorpion et SIT-V1.