Le MCO des systèmes d’information aujourd’hui 

L’IM 1618 pose les principes relatifs aux système principal / système de soutien et soutien initial / soutien en service. Cependant, il n’apparaît pas de dogme en matière de prise en compte financière du MCO des systèmes d’information (SI) très variable selon les acteurs. Il n’y a pas de critères prédéterminés relatifs à l’imputation au P146 ou au P178, ou encore au fait que le pilotage du soutien d’une opération d’armement ou d’un produit soit à un moment donné confié à un service de soutien ou reste à la DGA. La problématique est pour l’instant gérée au cas par cas. 

Par ailleurs, ne relevant d’aucun critère vraiment formalisé, la durée du soutien initial et la transition vers un soutien en service (sans que cela soit nécessairement couplé à une décision de MSO) dépend également de la maturité du produit et de son enjeu stratégique.

Le MCS et le MCO dans les SI doivent se concevoir dans une logique de PLM et de PDM

Vient se superposer à cela la logique gestion de biens, sachant que des opérations d’armement peuvent donner lieu à la désignation de multiples gestionnaires par composantes matérielles, et que la responsabilité du soutien est souvent par défaut attachée au gestionnaire de bien, cette bijection étant d’autant moins justifiée que l’on monte dans les couches applicatives. 

MCO et MCS 

Sur le plan technique, pour ce qui concerne le maintien en condition d’un système d’information, on distingue en principe : 

• la gestion du service et des incidents de service ; 
• l’infogérance : hébergement avec plusieurs niveaux de service, pouvant aller de la simple mise à disposition d’une infrastructure jusqu’à la réalisation de scripts spécifiques ; 
• le soutien matériel : serveurs et datacenters ; 
• et le maintien en condition de sécurité (MCS). 

L’objectif du MCS est de collecter, agréger et synthétiser les informations traitant des évolutions de la menace (c’est-à-dire la quantification de l’influence de l’environnement sur le système d’intérêt) et des vulnérabilités (c’est-à-dire la quantification de la réaction ou de l’absence de réaction du système d’intérêt vis-à-vis des influences de l’environnement). Il s’agit également de qualifier le risque (c’est-à-dire la combinaison d’un aléa, de sa probabilité a priori d’occurrence, de son impact sur le système d’intérêt, et de sa probabilité de non-détection) dans le temps et, bien entendu, de décider des actions à faire par rapport à ce risque : l’accepter, le réduire, le transférer ou l’annuler. En pratique, cela se traduit souvent techniquement par un déploiement de correctifs de sécurité, aux différents niveaux considérés pour le maintien en condition.

Le MCS est complémentaire du Maintien en Condition Opérationnelle (MCO) et doit s’articuler complètement avec lui. Il nécessite une expertise dans l’assistance au déploiement de correctifs de sécurité, dans l’assistance à l’application de mesures de sécurité, et dans le traitement des incidents de sécurité. Il ne peut être indépendant des infrastructures d’hébergement et des architectures système, logique, applicative des systèmes d’information concernés.

En outre, une particularité des SI est leur adhérence avec les données que ces systèmes manipulent (contenant et contenu ne font qu’un et ne peuvent s’envisager l’un sans l’autre). Gérer les données, c’est structurer, stocker, archiver, décrire, retrouver, tracer les versions, partager, et bien sûr protéger. Les problématiques de l’interopérabilité et de la connectivité entre multiples systèmes, ainsi que de l’ubiquité des buzzwords commme BI (business intelligence), DA (data anaytics), IA (intelligence artificielle), induisent de plus en plus de mécanismes automatiques : partager, convertir, corréler…

Ainsi le MCS et le MCO des SI doivent se concevoir dans une logique de PLM (Product Lifecycle Management) et de PDM (Product Data Management) : le PLM offre une vision globale orientée sur les modifications et les évolutions qui vont impacter le produit ; le PDM en est une partie consacrée à la création et la gestion des données de la conception. Avec ces concepts, le MCO des SI rejoint donc la problématique plus générale du MCO des systèmes non numériques.

Quelques écrans qui laissent l’utilisateur démuni, voire critique contre la maintenance…

Transformation numérique et DevOps 

L’accélération voulue des livraisons et la réduction des temps de cycle entre développement et mise en service, l’agilité requise dans la conception et la réalisation des SI, ont conduit ces dernières années à l’apparition du concept de DevOps, qui promeut cycles de développement courts, déploiements fréquents, voire livraisons continues. Le DevOps apporte davantage de soutien organisationnel pour maintenir du code, tout en facilitant la communication entre développeurs et administrateurs, ce qui entraîne une meilleure maintenance. 

Ceci est possible du fait du principe « you build it, you own it », qui souligne que celui qui développe un code informatique est aussi responsable pour son déploiement et sa maintenance. Bref, une responsabilité sur la partie du cycle de vie aval à son activité ; ce qui devrait être le cas dans tous les domaines. On passe de l’ingénierie système traditionnelle héritée des années 60 et résumée par la sérialité des activités de conception, réalisation, MCO, à une vision actuelle et en devenir de l’ingénierie système, où le « design for X » (X=évolutivité, maintenance, recyclage, réutilisation…) souligne ce regard systématique vers l’aval du cycle de vie du système, étape essentielle pour construire l’économie circulaire au niveau des systèmes complexes, appelée de ses voeux par le politique actuel et plus généralement les enjeux de société.

Le succès de la nouvelle UM SNUM ... sera quantifié par la valeur rendue à l'utilisateur final

Même si les organisations ne sont pas encore dans la pratique quotidienne du DevOps au Ministère, une plus grande collaboration entre les fonctions de réalisation et celles d’opérateur est essentielle, pour casser les silos artificiels entre pré-production et production, et permettre la continuité sans couture lors des mises en service (ou production dans le langage des SIC) des évolutions (fonctionnelles ou techniques) et mises à hauteur.

Il est temps de se transformer : les activités de l’opérateur (appliquer les mises à jour, surveiller les applications, mettre à hauteur l’infrastructure pour monter en performance : « scaling-up » en info-langue) sont tout aussi cruciales que les applications métier elles-mêmes, et leur gestion ne peut se concevoir sans un véritable dialogue intégré (différent de 2 monologues client-fournisseur !).

Espérons que la transformation de la DGA avec la création de l’UM SNUM, véritable équipe intégrée dans l’esprit, entre la DGA – dans sa responsabilité de conception des systèmes d’information – et l’EMA/DIRISI – dans sa responsabilité d’opérateur des systèmes d’information –, saura mettre en oeuvre une telle approche intégrative, seule garantie du succès éventuel de la démarche agile sponsorisée au plus haut niveau du Ministère, et qui ne saurait être quantifiée que par la valeur rendue à l’utilisateur final.

Dominique Luzeaux, IGA   L’IGA Dominique Luzeaux (X84) est en pleine transformation numérique, après avoir été terre à terre comme comme directeur de l’UM TER, et avoir pris de la hauteur auparavant dans les systèmes d’observation et d’information. Par ailleurs il est expert et formateur auprès de l’Ecole Polytechnique, pour l’ingénierie des systèmes complexes et le management de grands projets. Il est aussi l’auteur d’une dizaine de livres sur ces sujets.