La présente instruction fixe les règles relatives à la réalisation, au suivi en service et à la gestion des matériels et logiciels informatiques, non avionés, non intégrés à des systèmes de combat, de transmissions ou d'armes, et embarqués sur les bâtiments de la flotte pour la gestion du personnel, du matériel, du flotteur et l'aide aux opérations.

Les systèmes informatiques en question sont réalisés au moyen de matériels et progiciels du commerce non militarisés. Ils exploitent des logiciels d'application d'origines très diverses, traitant parfois des données à caractère centralisé, et susceptibles à court terme d'être connectés à des logiciels mis en œuvre par d'autres unités, services ou directions.

Les règles de conception et de maintenance des logiciels respectent le principe de l'organisation par chaînes fonctionnelles. Toutefois, la cohérence des systèmes embarqués et la communication entre logiciels supposent, outre le respect de standards de réalisation communs, l'existence de structures et de procédures permettant de coordonner leur développement et leur maintenance, entre les divers acteurs concernés, décideurs, réalisateurs ou utilisateurs.

Les directions et services rédigeront, si nécessaire, des circulaires d'application adaptées aux diverses chaînes fonctionnelles.

1. Structures de décision, de coordination et d'éxécution intéressant l'informatique embarquée.

L'informatique embarquée ne peut être considérée indépendamment de l'ensemble de l'informatique de la marine. Les structures définies ici concernent donc toutes les chaînes fonctionnelles et ont pour objectifs :

• de coordonner les activités informatiques sans toucher inutilement à l'autonomie de chaque chaîne fonctionnelle ;

• de pouvoir s'appliquer en toutes circonstances malgré la variété des situations résultant de la diversité des échelons de décision, des réalisateurs et des utilisateurs possibles ;

• de préciser le rôle de chaque centre informatique en fonction du cas considéré sans remettre en cause leur dispersion et l'ensemble de leurs activités nécessairement hétérogènes (gestion de matériel et logiciels, réalisation à différents niveaux, gestion de données, soutien des unités,…) ;

• de rendre transparente aux unités l'inévitable complexité des procédures.

1.1. Structures relatives aux matériels et aux logiciels (voir ANNEXE A ).

Comité directeur de l'informatique de la marine (CDIM) : la composition et le rôle du CDIM sont définis par la décision citée en référence c) Il arrête la politique de la marine en matière d'informatique, approuve le « schéma directeur opérationnel » (scénario global d'évolution des système d'information) et affecte les moyens financiers correspondants.

Comité de direction par domaine : trois comités sont respectivement chargés des systèmes d'information concernant :

• l'aide aux opérations (CDAO) ;

• la gestion administrative et militaire du personnel et la bureautique (CDGAM) ;

• la gestion du matériel et l'aide à l'entretien et à la conduite du flotteur (CDGMEF).

Responsables, chacun dans son domaine, du contrôle de la cohérence et de l'interopérabilité des systèmes d'information développés par les différentes composantes de la marine, ils proposent au CDIM les évolutions devant figurer au schéma directeur opérationnel de la marine et soumettent à son arbitrage les options susceptibles de le remettre en cause. Ils examinent uniquement les aspects techniques, économiques et sécurité des projets, et ils ne se prononcent pas sur les besoins fonctionnels les motivant.

La composition des comités de direction est fixée par le président du CDIM.

Division « programmes », bureau « transmissions et systèmes d'information et de commandement (TSIC ») : chargé notamment de la coordination en matière de systèmes d'information, il est responsable de la cohérence de l'ensemble des projets. Il diffuse les normes, standards et contraintes à respecter pour le développement de tous les systèmes destinés à être installés dans des unités opérationnelles ou à échanger des informations avec elles.

Il assure le secrétariat permanent des différents comités de direction.

Maître d'ouvrage : la maîtrise d'ouvrage d'un projet informatique est normalement assurée par l'échelon central de la chaîne fonctionnelle décidant de sa réalisation. Elle peut être déléguée à un organisme subordonné mais elle ne peut jamais être totalement confiée à un centre informatique, qu'il soit interne ou externe à la marine.

Les responsabilités du maître d'ouvrage et les instances pouvant être constituées pour la conduite de projets importants (comité directeur, comité exécutif ou de pilotage, groupe de direction de projet ou équipe de marque…) sont définies par le document cité en référence d). Dans la marine, il appartient également au maître d'ouvrage :

• de soumettre le projet au comité de direction concerné, et s'il y a lieu à la structure permanente des données de la marine (cf. 1.2), via le bureau « transmissions et système d'information et de commandement » (PROG/TSIC) ;

• de désigner ou de provoquer la désignation d'une ou plusieurs autorités pilotes représentant les utilisateurs et s'il y a lieu d'un expert ;

• de qualifier (A) et d'homologuer (A) le système d'information ou le logiciel d'application réalisé et de fixer les modalités de mise en service et d'exploitation.

Autorité pilote : autorité désignée pour représenter les utilisateurs d'un système d'information ou d'un logiciel d'application. Pour une réalisation nouvelle ou une modification fonctionnelle importante, elle désigne un « représentant » ou des représentants constituant un « comité utilisateurs » (ou « comité de validation ») chargé :

• d'exprimer les besoins des utilisateurs et de rédiger ou de valider les spécifications opérationnelles ;

• de valider les solutions proposées au plan fonctionnel par le maître d'œuvre ;

• de représenter éventuellement le maître d'ouvrage à la recette et de diriger l'évaluation.

Après homologation et mise en service d'un logiciel, l'autorité pilote approuve les demandes des modifications fonctionnelles et en fixe les priorités de réalisation.

Dans le cas d'un projet important concernant des utilisateurs ayant des besoins différents plusieurs autorités pilotes peuvent être désignées. Leurs représentants participent au « comité utilisateurs » constitué, dans ce cas, par la maîtrise d'ouvrage pour la phase de réalisation.

L'autorité pilote joue un rôle essentiel en phase d'étude et ses avis sont déterminant pour apprécier l'opportunité d'une réalisation ou d'une modification. Mais elle n'a pas de pouvoir exécutif direct et ses options importantes doivent être approuvées par la maîtrise d'ouvrage, responsable du financement.

Expert : organisme ou personne morale spécialiste du domaine traité et chargé de valider les algorithmes ou les traitements informatiques proposés par le maître d'œuvre. Un expert est désigné par le maître d'ouvrage quand le projet nécessite des connaissances scientifiques ou une maîtrise de la réglementation dont les simples utilisateurs et le maître d'œuvre peuvent être dépourvus.

L'expert peut être désigné, soit pour assister directement la maîtrise d'ouvrage, soit pour assister une autorité pilote.

Maître d'œuvre : organisme ou personne morale chargé de la réalisation d'un projet, le maître d'œuvre est l'unique responsable vis-à-vis de la maîtrise d'ouvrage, y compris lorsque la maîtrise d'œuvre est totalement sous-traitée. Il peut être assisté d'un « groupe de projet ».

Les responsabilités du maître d'œuvre et le rôle du groupe de projet sont définis dans le document cité en référence d).

Dans la marine, la maîtrise d'œuvre d'un projet peut être confiée :

• soit à un maître d'œuvre interne :

  • centre informatique rattaché au bureau PROG/TSIC ;

  • centre informatique ou centre d'étude dépendant d'une direction ou d'un service central agissant dans son domaine de compétence [limité pour ce qui concerne la direction des constructions navales (DCN) à l'entretien de la flotte] ;

• soit à un maître d'œuvre externe ;

  • société privée ;

  • centre industriel de la délégation générale pour l'armement (DGA) (DCN ingénierie par exemple).

Les maîtres d'œuvre internes doivent s'assurer de la pérennité des ressources humaines et matérielles nécessaires à la maintenance des logiciels qu'ils ont réalisés.

Centre de suivi logiciel (CSL) : organisme « étatique » à compétence informatique chargé d'assister le maître d'ouvrage et l'autorité pilote pour la définition des besoins, le contrôle de la maîtrise d'œuvre et l'organisation de la maintenance d'un logiciel. Cette fonction est exercée par un centre informatique de la chaîne fonctionnelle concernée.

Dans le cas d'une maîtrise d'œuvre interne, il s'agit normalement du centre chargé de la réalisation qui, étant à la fois maître d'œuvre et CSL, doit désigner un responsable distinct du chef de projet. Quand la réalisation est confiée à un maître d'œuvre interne n'appartenant pas à la chaîne fonctionnelle du maître d'ouvrage, ce dernier peut attribuer les fonctions de CSL, soit au maître d'œuvre, soit à un centre qui lui est directement subordonné.

Le CSL participe aux divers « comités exécutifs (ou de pilotage) » éventuellement constitués pour la réalisation de grands projets, mais il conserve des attributions au-delà du développement. Après mise en service d'un logiciel, le CSL :

• conserve les fichiers sources et la documentation afin de préserver les possibilités d'évolution en cas de défection du maître d'œuvre (les marchés doivent être établis dans cette optique) ;

• instruit et traite, avec l'accord du maître d'ouvrage quand il y a lieu, les demandes d'évolution approuvées par l'autorité pilote.

Organisme centralisateur du matériel (OCM) : organisme de la DCN chargé du suivi du matériel en service, et dans certains cas des logiciels associés. Ses attributions sont définies par l'instruction citée en référence e) et consistent principalement à :

• tenir à jour et diffuser la documentation technique et logistique ;

• étudier et proposer au département les modifications du matériel et des règles de maintenance ;

• suivre la situation des rechanges et provoquer toute action nécessaire pour maintenir les stocks à un niveau convenable ;

• assurer la formation du personnel chargé de l'entretien.

Le bureau technique du service central de l'aéronautique navale (SC AERO) et le service d'approvisionnement en matériel de l'aéronautique navale (SAMAN) ont des attributions comparables pour les matériels et logiciels de l'aéronautique navale.

Centre de coordination informatique (CCI) : organisme chargé de gérer, recueillir et instruire les besoins informatiques des unités qui lui sont rattachées, il a pour tâches principales :

• de tenir à jour la situation des matériels et logiciels ;

• d'intégrer les applications nouvelles dans leur environnement et de les diffuser ;

• de recueillir et d'analyser les besoins des unités tant au plan matériel que logiciel ;

• d'assister les unités rencontrant des difficultés imputables aux applications, éventuellement aux systèmes d'exploitation et aux utilitaires ;

• de coordonner entre le département, les utilisateurs, et les différents organismes concernés, les essais des matériels et logiciels d'application ;

• d'expérimenter des matériels et progiciels à la demande du département.

Il est tenu informé des réalisations nouvelles intéressant ses unités rattachées et de leurs développements afin de prévoir les évolutions matérielles nécessaires, participer aux essais et contribuer ultérieurement au suivi.

Il veille en particulier à l'harmonisation et à la cohérence des applications ainsi qu'à l'adéquation des matériels et des progiciels installés sur les unités et dans les écoles pour la formation ; à cette fin, il propose au bureau PROG/TSIC :

• les standards de réalisation et d'installation logiciels propres aux unités administrées ;

• les évolutions de configurations matérielles ;

• les améliorations à apporter à la formation du personnel en matière de systèmes d'exploitation.

Proche des utilisateurs embarqués, il peut également spécifier, à la demande du maître d'ouvrage et pour le compte du CSL, des logiciels ou des modifications de logiciels en service.

Le centre d'analyse opérationnelle et d'informatique de la flotte (CALOIF) et le CCI des bâtiments de la flotte et des sous-marins d'attaque. Le centre d'entraînement et d'instruction des sous-marins nucléaires lanceurs d'engins (CEISNLE) est le CCI des SNLE.

Toutefois le CALOIF centralise les demandes d'évolution en matière de standards, de configurations matérielles et de formation.

Le CCI est le correspondant normal d'une unité pour l'ensemble des questions informatiques la concernant à l'exception : des demandes de concours du ressort des services réparateurs (cf. 2.3 suivant) ; des échanges de données avec les centres supports (cf. 1.2 suivant) ; des questions relatives aux logiciels et matériels de l'aéronautique navale embarqués à bord des porte-avions (cf. 2.6 suivant).

Remarque : il n'existe pas de CCI pour les unités à terre ; dans ces unités, chaque chaîne fonctionnelle dispose de correspondants particuliers et l'informatisation ne présente pas les mêmes difficultés (espace limité, partage du matériel et des réseaux,…), ni les mêmes besoins de standardisation qu'à bord des bâtiments.

En pratique, les centres informatiques propres à chaque chaîne fonctionnelle assurent, dans leurs domaines respectifs, les fonctions de CCI pour les unités à terre.

1.2. Structures relatives à la gestion des données (voir ANNEXE B ).

Les données utilisées par les systèmes informatiques peuvent être :

• « spécifiques » à un système ou « communes » à plusieurs systèmes ;

• « quasi permanentes » ou « éphémères ».

Les données doivent être gérées de manière à garantir leur validité et l'unicité des valeurs, et permettre leur exploitation commune par différents systèmes.

Les catalogues des données de la marine : approuvés et diffusés par l'état-major, donnent la liste des données quasi permanentes, leurs formats, leurs gestionnaires et l'administrateur de la base de données de référence quand elle existe.

Les formats définis par ces documents sont utilisés pour les échanges entre systèmes.

Source de données : les données quasi permanentes proviennent, sous forme informatique ou non, d'un organisme compétent dans le domaine considéré et détenant ou non une « base de données source (BDD source) ».

Gestionnaire de données : autorité ou organisme désigné pour chaque type de donnée et chargé :

• de proposer la mise à jour des catalogues de données dans le domaine qui lui revient (liste et formats) ;

• de la sélection de la meilleure valeur parmi celles provenant de différentes sources ou proposées par les utilisateurs et de la validation des données ;

• de la transmission des données validées à l'administrateur de la « base de données de référence (BDDR) ».

Les gestionnaires de données sont désignés par le département.

Administrateur de base de données de référence : organisme chargé de la tenue à jour d'une base de données de référence. L'administrateur d'une BDDR peut être le gestionnaire des données ; mais une BDDR peut contenir des données de différentes natures et relever de ce fait de divers gestionnaires.

L'administrateur est responsable :

• de l'évolution des structures de la base et de son organisation ;

• de la gestion des autorisations d'accès ;

• de l'intégration et de la saisie des données validées par les gestionnaires ;

• de la distribution des données aux centres supports.

Centre support de données : organisme désigné pour chaque système informatique et chargé :

• de l'adaptation technique des données entre la BDDR et les bases de données utilisateurs ;

• de la distribution des données aux utilisateurs sous la forme et selon la périodicité adaptées ;

• du recueil et de la synthèse des propositions de mise à jour des données provenant des utilisateurs.

Les centres supports nécessaires sont désignés par le maître d'ouvrage du système concerné qui définit également les procédures de gestion des données en fonction des moyens dont sont dotés les différents organismes concernés.

Structure permanente d'administration des données de la marine (SPADOM) : comité regroupant des représentants des organismes « sources », des gestionnaires de données, des maîtres d'ouvrages, des autorités pilotes de systèmes qui se réunit périodiquement pour :

• examiner la progression des travaux relatifs à l'élaboration des catalogues et des bases de données ainsi que les services rendus ;

• coordonner les activités des différents organismes responsables ;

• tenir à jour l'état des structures de gestion des données et des systèmes concernés.

Une instruction particulière traite de l'administration des données et définit les divers gestionnaires avec leurs attributions respectives.

2. Le matériel informatique des bâtiments de la flotte.

2.1. Installation.

Les matériels informatiques concernés sont des matériels du commerce non militarisés. Les configurations matérielles de chaque type de bâtiments et l'implantation du matériel à bord des bâtiments sont définies par le département.

L'installation du matériel, des réseaux et des systèmes d'exploitation incombe à la DCN, en liaison avec les CCI. Les supports des systèmes d'exploitation et des utilitaires sont remis au bord à cette occasion avec les clefs d'installation.

Les bâtiments sont équipés de systèmes d'exploitation en version exécutif dépourvus de compilateur.

Les droits d'accès aux commandes et aux fichiers du systèmes d'exploitation sont définis et installés par le CCI.

Des permutations provisoires de matériels visant à préserver le fonctionnement des installations en fonction des priorités du moment peuvent être effectuées à l'initiative des bords. En dehors de ce cas, les demandes de modifications aux installations sont adressées au CCI qui soumet les besoins au département.

2.2. Gestion.

Les matériels informatiques embarqués sont considérés comme des « matériels fixes ». Ils sont confiés à un service par ordre du commandant. Ce service est chargé de la gestion et de l'entretien du matériel ainsi que de l'administration des réseaux existants. Le chef du service désigné est secondé par un officier marinier possédant la mention « systèmes d'exploitation » dit « responsable systèmes ».

Les autres services utilisateurs désignent un officier marinier ayant reçu la formation « super-utilisateur » correspondant du « responsable systèmes » pour tout ce qui concerne la gestion et l'entretien.

2.3. Maintenance.

La politique de maintenance du matériel est définie par l'état-major de la marine (EMM). La maintenance préventive et corrective du premier degré est effectuée par le responsable systèmes conformément à la documentation technique délivrée avec le matériel. Cette documentation est constituée :

• des notices constructeur remises à l'installation du matériel ;

• du document de politique de maintenance ;

• du « guide de maintenance et d'entretien ».

Les demandes de concours pour réparation sont soumises aux règles habituelles définies dans chaque port. Le CCI est mis en information des demandes d'intervention quand le fonctionnement du système d'exploitation ou des applications est suspecté.

Les interventions touchant à un matériel, à des éléments logiciels ou à des données protégés sont soumises aux règles relatives à la protection du secret dans la marine.

2.4. Utilisation.

Les utilisateurs se conforment aux notices du constructeur et aux guides pratiques délivrés par le CCI à l'intention des opérateurs, des super-utilisateurs et du responsable systèmes.

Les guides pratiques du CCI définissent en particulier :

• les procédures d'installation des logiciels d'application et de sauvegarde à l'usage des super-utilisateurs ;

• les procédures d'installation des systèmes d'exploitation et des logiciels utilitaires du ressort du responsable systèmes.

2.5. Consommables.

Les supports magnétiques, les fournitures pour imprimantes et le matériel de nettoyage sont délivrés par le service des approvisionnements de la flotte et facturés sur le crédit en valeur des unités.

La gestion des supports magnétiques est soumise aux règles fixées par l'instruction sur la sécurité des systèmes d'information (cf. 5).

2.6. Cas des matériels et logiciels spécifiques à la chaîne fonctionnelle « SC AERO ».

La maintenance et la gestion des matériels et des logiciels de l'aéronautique navale embarqués à bord des porte-avions sont directement assurés par le SC AERO. A bord des porte-avions, elles relèvent du chef du service technique aéronautique (CSTA) qui dépend du SC AERO. De même les approvisionnements en consommables standards (gestion décentralisée) ou en consommables spécifiques (gestion centralisée) sont financés par le SC AERO.

3. Réalisation, gestion et maintenance des logiciels d'application des bâtiments.

3.1. Réalisation des logiciels.

3.1.1. Principes.

Les réalisations nouvelles et les évolutions importantes de logiciels d'application sont décidées par l'échelon central de la chaîne fonctionnelle concernée (maître d'ouvrage). Quand les logiciels sont destinés à des bâtiments, ils sont soumis au visa du bureau PROG/TSIC de l'état-major, après avis du comité de direction concernée et, présentés, s'il y a lieu, au CDIM.

Les standards de réalisation (matériel, progiciel, documentation, interfaces hommes-machines, implantation des fichiers, échanges de données) sont définis par l'état-major. Le CALOIF centralise et soumet à l'état-major les propositions d'évolution des standards informatiques.

3.1.2. Procédures relatives à la réalisation des logiciels (voir ANNEXE C ).

La réalisation d'un logiciel peut être initialisée par l'EMM, les directions et services dans le cadre de la chaîne fonctionnelle ou provenir d'une demande des organismes utilisateurs.

Dans ce dernier cas, les demandes de réalisation de logiciels d'applications provenant des unités sont adressées à leur autorité organique qui retransmet au CCI quand elle le juge utile. Un modèle de fiche d'expression de besoin figure en annexe E. Une expression de besoin peut utilement être accompagnée d'une maquette réalisée par le demandeur.

Le CCI soumet les demandes, complétées quand il y a lieu d'un avis technique de faisabilité, à l'échelon concerné (EMM, direction ou service, autorité organique exerçant une fonction de direction générale) en tenant informé le bureau « PROG/TSIC ».

Les projets intéressant les bâtiments, quelle que soit leur voie d'initialisation, sont systématiquement communiqués au bureau PROG/TSIC, avec les CCI concernés en information, dès la phase d'étude d'opportunité, afin de vérifier les liens et les incidences possibles avec les systèmes en service.

A l'issue de l'étude préalable, le maître d'ouvrage soumet le projet au comité de direction concerné par la voie de son secrétariat permanent, en indiquant :

• la finalité du logiciel, et éventuellement les systèmes et applications qui seront remplacés ;

• le matériel, le système d'exploitation et les progiciels envisagés ;

• la nature et la confidentialité des données traitées, ainsi que les critères de sécurité éventuellement exigés pour le système ;

• la ou les autorités pilotes proposées ;

• s'il y a lieu, le ou les experts choisis ;

• le maître d'œuvre et le CSL envisagés ;

• les modalités particulières éventuelles de développement, de maintenance et de financement ;

• en l'absence de financement déjà prévu, l'évaluation des coûts.

Le projet est examiné à l'occasion de la réunion suivante du comité de direction concerné et, s'il y a lieu (désaccords d'ordre technique, remise en cause du schéma directeur, besoin d'un financement particulier,…) soumis à la décision du CDIM. En cas d'incidence sur la sécurité, le cahier des charges est soumis au visa du bureau chargé de la sécurité des systèmes d'information (EMM/SSI).

Après approbation du projet, le maître d'ouvrage :

• notifie l'ordre de réalisation à l'un de ses centres informatiques ou ordonne le marché selon les procédures propres à chaque chaîne fonctionnelle ; toutefois la désignation d'un centre informatique de la marine relevant du bureau « PROG/TSIC », en tant que maître d'œuvre interne ou CSL, est du ressort de ce bureau ;

• désigne ou provoque la désignation des experts éventuellement nécessaires et des autorités pilotes, qui désignent elles mêmes leurs représentants chargés de la rédaction des spécifications opérationnelles avec le concours du CSL ;

• informe les CCI concernés à terme par le projet.

Le bureau « PROG/TSIC » et les CCI concernés sont informés des décisions modifiant les dispositions arrêtées antérieurement.

Les travaux éventuellement nécessaires aux échanges de données entre systèmes sont financés par le maître d'ouvrage du système recevant ces données.

Sauf dispositions contraires définies par le maître d'ouvrage, la « vérification de service régulier » (VSR) est effectuée par l'autorité pilote avec le concours du CSL et de l'expert éventuel. Si l'importance du système le justifie, la VSR peut être supervisée par une commission particulière d'essai constituée à la demande du maître d'ouvrage.

La « vérification de conformité », pour le compte du bureau PROG/TSIC, est effectuée à cette occasion par le ou l'un des CCI concernés.

La « qualification » d'un logiciel est prononcée par le maître d'ouvrage sur proposition de l'autorité pilote.

« L'évaluation » dirigée par l'autorité pilote est organisée avec le concours du CSL et des CCI concernés. L'autorité pilote centralise les demandes d'évolution émises à cette occasion et les classe par ordre de priorité. Elles sont traitées par le CSL comme des opérations de maintenance.

3.2. Homologation des logiciels.

Pour être homologué, un logiciel doit être « qualifié » et répondre de manière acceptable aux besoins des utilisateurs.

L'homologation suppose également la livraison préalable :

• par un maître d'œuvre externe au CSL, des fichiers sources et de l'ensemble de la documentation dont le dossier de programmation, et sur demande le dossier de présentation ;

• par le CSL aux CCI concernés :

  • de la dernière version du logiciel exécutable ;

  • du guide utilisateur ;

  • si l'importance du logiciel le justifie, d'un dossier de formation qui sera délivré au centre d'instruction concerné à l'occasion de la formation de ses instructeurs.

L'homologation d'un logiciel est prononcée par le maître d'ouvrage sur proposition du CSL approuvée par l'autorité pilote. Elle définit :

• la liste de diffusion du logiciel ;

• les modalités éventuelles de mise en service ;

• s'il y a lieu, la composition de la « commission de modification » ;

• le ou les centres supports de données, ainsi que les règles de gestion des données du système.

La décision de retrait de service d'un logiciel est également prononcée par le maître d'ouvrage sur proposition du CSL approuvée par l'autorité pilote.

3.3. Diffusion et installation des logiciels.

Les CCI :

• définissent les procédures logicielles d'installation ;

• dupliquent et diffusent les logiciels homologués.

Le CSL, avec le concours éventuel des CCI :

• forme les utilisateurs lors de la diffusion de la première version ;

• enseigne leur exploitation aux instructeurs des écoles et des forces, et propose quand nécessaire les modifications à apporter aux programmes de formation du personnel de la marine pour tenir compte des applications mises en service.

Les logiciels retirés du service sont également désinstallés par les CCI.

3.4. Maintenance des logiciels.

3.4.1. Généralités.

La maintenance des logiciels comprend les « corrections », les « modifications fonctionnelles » et les « modifications techniques ».

Ces interventions peuvent également être classées « mineures » ou « majeures » en fonction de l'importance des travaux, de leurs conséquences et des modalités de financement. Une intervention est classée « majeure » dès lors qu'elle présente des difficultés de financement réclamant l'aval du maître d'ouvrage (intervention hors garantie ou hors du cadre d'un maintien en condition opérationnelle) ou entraîne des conséquences techniques intéressant le bureau PROG/TSIC. La classe de l'intervention est attribuée par le CSL.

Les modifications techniques ne concernent normalement pas les utilisateurs et ne sont pas traitées ici.

3.4.2. Procédures relatives aux corrections et modifications fonctionnelles (voir ANNEXE D ).

Les demandes sont adressées au CCI de rattachement, soit à l'occasion des comptes rendus annuels de disponibilité informatique, soit au plus tôt en cas de défaut pénalisant. Les demandes ponctuelles et urgentes sont traitées au plus tôt.

Des modèles de fiches de demande de correction et de modification figurent respectivement en annexes F et G.

Le CCI examine les demandes, vérifie que les erreurs de manipulation, le vieillissement des inscriptions ou des insuffisances de la documentation ne sont pas la cause des anomalies. Il recherche les incidences possibles des évolutions sur les matériels ou sur la conception et la sécurité des autres logiciels installés ou en cours de réalisation.

Une demande de correction qui se révélerait être une demande de modification, serait traitée comme telle et réciproquement.

Après examen :

• les demandes de corrections sont adressées au CSL qui établit la synthèse pour le maître d'œuvre ;

• les demandes de modification sont adressées pour avis à l'autorité pilote qui retransmet les modifications retenues au CSL en indiquant les priorités.

• a).  Les corrections sont normalement effectuées sans autre examen par le maître d'œuvre.

  En cas de difficulté d'ordre technique ou financier, il appartient au maître d'œuvre d'en informer le CSL qui classe alors l'intervention « majeure » et soumet la question au maître d'ouvrage.

• b).  Les modifications fonctionnelles sont adressées au maître d'œuvre accompagnées, si l'importance de la modification le justifie, des spécifications établies par le CSL et approuvées par l'autorité pilote.

Le maître d'œuvre adresse au CSL un « dossier de proposition de modification » indiquant :

• les délais de réalisation ;

• le devis prévisionnel de la modification ;

• les difficultés et conséquences éventuelles.

Quand tous les éléments sont réunis, le CSL classe la modification « intervention mineure » ou « intervention majeure », et :

• notifie la réalisation des modifications mineures au maître d'œuvre ;

• propose les modifications majeures au maître d'ouvrage qui décide, avec le concours de la commission de modification quand elle a été désignée, des modifications retenues et des priorités.

En l'absence de financement prévu ou lorsque l'environnement matériel ou logiciel est touché, les modifications majeures sont traitées comme des réalisations nouvelles ; le projet de modification est alors soumis à la commission de contrôle concernée.

Dans le cas contraire, la décision de modification est notifiée au maître d'œuvre par la voie hiérarchique ou suivant les procédures propres à chaque chaîne fonctionnelle.

Pour toute « modification majeure », et sur demande du CSL pour une « modification mineure », le maître d'œuvre adresse au CSL et aux CCI concernés un « dossier de modification » donnant :

• la description détaillée de la modification ;

• les modalités de recette des éléments logiciels modifiés ;

• les modifications à apporter à la documentation.

Après toute intervention, correction ou modification, les fichiers sources et les applicatifs de la nouvelle version du logiciel sont respectivement remis au CSL pour conservation et aux CCI pour diffusion.

4. Informatique « privée » des unités.

Afin de ne pas limiter les initiatives individuelles, chaque unité peut développer pour son propre usage les applications dont elle a besoin, à condition de ne pas utiliser de fichier ou de module de traitement d'un logiciel homologué ou en évaluation sans l'accord formel du CCI. Ces développements sont effectués sur un calculateur configuré par le CCI en version développement et isolé d'un réseau. Pour préserver les possibilités ultérieures de diffusion ou de communication avec d'autres systèmes, les progiciels utilisés seront choisis dans le catalogue diffusé par le département.

Il appartient à chaque autorité organique de contrôler que l'utilisation des applications réalisées par les unités respectent les règlements en vigueur concernant la protection du secret. Les applications doivent recevoir une protection au moins égale à celle des informations qui y sont traitées.

Chaque fois que leur intérêt le justifie, les applications réalisées par les unités doivent faire l'objet d'une demande d'homologation adressée à l'autorité organique qui, si elle le juge utile, transmet la demande au CCI concerné.

Le CCI examine les logiciels et, après avis des services ou directions concernés, propose leur homologation ou leur réécriture.

5. Sureté et sécurité des informations.

5.1. Informatique et liberté.

La création sur support magnétique de fichiers d'informations nominatives est interdite sans déclaration préalable auprès de la commission nationale de l'informatique et des libertés (CNIL). Pour la marine, cette déclaration est effectuée par le bureau « PL/ORA » à partir des éléments fournis par les CCI.

5.2. Sécurité informatique.

Les règles à respecter en matière de sécurité informatique sont définies par l'instruction sur la protection du secret dans la marine.

Dans l'attente d'une instruction traitant plus précisément de la sécurité des systèmes d'information, il convient d'appliquer les règles pratiques proposées par le document cité en référence f).

6. Comptes rendus des utilisateurs.

Afin de tirer profit de l'expérience pour améliorer les moyens informatiques embarqués, les unités établissent en avril un « compte rendu de disponibilité informatique » conforme au modèle figurant en annexe H.

Des fiches de demande de correction, de modification ou de réalisation de logiciels d'application peuvent être jointes à ce compte rendu ou adressées séparément au CCI.

Les CCI établissent une synthèse des comptes rendus et des fiches reçus dont l'état-major de la marine, les autorités organiques, les autorités pilotes et les CSL sont destinataires.

Cet ensemble constitue le support normal pour l'information des autorités et organismes concernés.

7.

L'instruction provisoire n^o 5/EMM/PL/MTA du 7 janvier 1987 et l'instruction n^o 149/EMM/MAT/INF du 16 mars 1980 sont abrogées.