Certes on ne concevrait plus le SCCOA maintenant comme on l’a fait à ses débuts, mais il est intéressant de passer en revue quelques concepts et problèmes de l’époque, car le passé, surtout récent, donne sur l’avenir des éclairages utiles.

Je me concentrerai sur les systèmes informatiques. Pour une autre vision des premiers pas du SCCOA, on pourra se reporter à un article paru dans le livre du cinquantenaire.

Un besoin de renouveau tiré par la croissance de la complexité et par l’OTAN

La mise en place du SCCOA a été déclenchée par la progression de la conception du système ACCS (Air command and control system) de l’OTAN, mais la démarche était inéluctable.

Il fallait définir une architecture d’ensemble et des spécifications permettant de maîtriser les interactions entre systèmes d’information (SI) divers. Vu la taille des logiciels à interfacer, il s’agissait plutôt de gestion centralisée de l’interopérabilité appuyée sur une vision globale rigoureuse.

Pour assurer l’interopérabilité, l’une des premières décisions fut celle de prévoir l’utilisation des logiciels de l’ACCS, d’une part parce que des logiciels communs assurent la cohérence, et d’autre part parce que la France en aurait de toute façon financé le développement comme elle avait continué à financer le NADGE (NATO air defence ground environment) après 1966. 

Comme l’ACCS, le SCCOA regroupait les SI de la Défense aérienne, de la Force aérienne tactique (FATAC), de la reconnaissance et du transport. Une approche globale était également nécessaire pour les avions multirôle, notamment le Rafale dont le programme progressait. 

Le nucléaire restait en dehors, principalement pour des raisons de confidentialité.

Quelques pièges de l’interopérabilité

Je les illustrerai par des anecdotes vécues. Je n’ai certainement pas tout détecté et le numérique moderne en réserve assurément de nouveaux …

La plupart de ces anecdotes renvoient à des insuffisances de la communication entre des équipes ou des personnes contribuant au développement de systèmes en interaction. Il faut essayer de détecter ces défauts même lorsqu’on ne maîtrise pas les domaines techniques concernés, ce qui est assez fréquent dans des systèmes très complexes.

Détecter les illusions sur l’interopérabilité. Un gros groupe industriel avait convaincu l’EMAA (État-major de l’Armée de l’air) qu’il pouvait fournir un système (disons « X ») capable de fonctionner en interaction avec le SCCOA sans travaux préalables. Je demandai à notre contact dans ce groupe comment étaient gérés les automatismes dans les fonctions interagissantes du SCCOA et du système X ; réponse : « je ne sais pas, mais je peux vous faire rencontrer un spécialiste qui vous expliquera ». Il y eut une première réunion, puis une deuxième, avec à chaque fois la même réponse, et enfin à la troisième le véritable expert que nous rencontrions répondit à ma question : « c’est vous qui me le dites ». Bonne illustration de l’ambiguïté du terme « interopérabilité », trompant même des professionnels de bonne foi.

Lutter contre la rétention d’informations. La tendance est forte entre industriels, pour essayer de protéger le savoir-faire. Le cas le plus typique que j’ai connu n’était pas du SCCOA, mais proche  : il s’agissait de l’interopérabilité entre les AWACS et le PA-CDG. DCNS, en voie de transformation en société commerciale, pressentait une concurrence avec Thalès sur le numérique et ne voulait pas donner d’informations sur le traitement des informations échangées par la Liaison 16 (L 16). En conséquence de ce refus, l’ingénieur en charge de la Liaison 16 de notre côté était réticent à donner des documents sur les traitements L 16 dans l’AWACS. Je décidai que nous communiquerions des copies des documents sans contrepartie, ce qui fut fait, et les essais opérationnels se déroulèrent très bien.

Faire la part du feu. Certains processus présentent des divergences qu’il vaut mieux considérer comme irréconciliables. Je pense en particulier à la synthèse des détections des radars au niveau national et au niveau local : malgré des millions de francs d’investissements (avant le SCCOA) ces visions des pistes d’aéronefs dans l’espace n’étaient presque jamais en plein accord ; toutes les fois que j’ai visité un CLA (Contrôle local d’aérodrome), je me suis fait présenter les deux jeux de pistes superposés (car la liaison et la fonction existaient) et il y avait toujours des différences, conduisant les opérateurs locaux à n’afficher que les données locales sur leurs écrans. Je ne pense pas que la question ait été totalement résolue depuis. 

Attention aux exigences extrêmes. Il est toujours tentant, pour celui qui livre un logiciel complexe dépendant des performances de systèmes extérieurs, de demander des performances maximalistes et extrêmement coûteuses sans justification réelle . Je me souviens en particulier que la société chargée des logiciels du STRIDA exigeait que les liaisons avec les radars soient effectuées par des lignes dédiées « point à point », alors que le réseau à commutation de paquets TRANSPAC était beaucoup moins onéreux. Je fis faire par le CELAR une simulation, qui démontra que la probabilité de perte d’informations était extrêmement faible et le sujet fut clos au bénéfice de la commutation de paquets.

Conclusion 

Le SCCOA a déjà beaucoup évolué depuis une trentaine d’années. Les évolutions majeures du big data et du deep learning lui apporteront certainement des capacités nouvelles, indispensables pour «  rester dans la course ». Mais l’augmentation de complexité qui en résultera ne permettra pas de résoudre tous les problèmes d’interopérabilité et en posera probablement de nouveaux. Là encore l’intuition jouera un rôle important, car lorsque l’on commence à aborder la complexité, il faut prendre des décisions sans avoir accès aux détails que l’on ne connaîtra que plus tard et dont certains présentent de toute façon une complexité qui dépasse le potentiel des méthodes et outils utilisables.