> Télécharger au format PDF
Archivé Direction générale des systèmes d'information et de communication :

INSTRUCTION N° 2005/DEF/DGSIC relative aux modalités d'examen des systèmes d'information et de communication.

Du 22 juillet 2010
NOR D E F E 1 0 5 1 5 4 2 J

Autre(s) version(s) :

 

1. OBJET.

Les articles 6., 10. et 13. de l\'arrêté du 6 juin 2006 portant création et organisation d\'instances relatives aux systèmes d\'information et de communication du ministère de la défense, disposent que les commissions relatives aux segments de l\'informatique du ministère examinent et approuvent les projets des états-majors, directions et services selon des modalités définies par des instructions particulières.

L\'article 3. alinéa 5. du décret n° 2006-497 du 2 mai 2006 stipule que le directeur général des systèmes d\'information et de communication (DGSIC) évalue, au regard des éléments qui lui sont fournis par les responsables mentionnés ci-dessous, la pertinence et la cohérence des projets, notamment les projets d\'acquisition de systèmes, produits ou services informatiques et de télécommunications d\'usage général ou commun.

Dans la suite du document, les commissions relatives aux systèmes d\'information opérationnels et de communication (SIOC) et aux systèmes d\'information d\'administration et de gestion (SIAG), placées respectivement sous la responsabilité du chef d\'état major des armées et du secrétaire général pour l\'administration sont appelées simplement commissions.

La présente instruction uniformise les modalités d\'examen des systèmes d\'information, tous segments confondus, et abroge, le cas échéant, les instructions précédentes. Elle ne s\'applique pas aux systèmes d\'information scientifiques et techniques, mais pourra servir de guide pour la constitution du processus de gouvernance du domaine.

2. DOMAINE D'APPLICATION.

Tout système d\'information et de communication, quel que soit son mode de réalisation, de maintien en condition opérationnelle, de sécurité, ou de financement doit faire l\'objet d\'examens durant sa vie et recevoir l\'approbation de la commission dont il relève, selon des modalités définies ci-dessous.

En ce qui concerne les SIOC, l\'examen de la convergence interarmées est de la compétence du comité de convergence des SIOC (COVESIOC) et non directement de la commission des SIOC. S\'agissant des opérations d\'armement, le cycle d\'examen des projets obéit aux principes et s\'inscrit dans le cadre des responsabilités définis par l\'instruction 1516 (n.i. BO) sur la conduite des opérations d\'armement.

L\'étude, le financement, la conception, la réalisation, la mise en service, la mise en réseau, l\'exploitation, l\'hébergement, le soutien d\'applications ou de systèmes informatique ou de télécommunications qui n\'auraient pas été approuvés par l\'une des trois commissions visées par la présente instruction sont interdits au sein du ministère de la défense.

3. EXAMEN DES SYSTÈMES.

3.1. Principes.

L\'examen des systèmes par la commission concernée se produit en principe à l\'occasion des principaux jalons sanctionnant le franchissement des phases de la vie du système d\'information. Ces jalons sont identiques, dans leur principe, à ceux prévus par l\'instruction générale 1516 (n.i. BO) sur le déroulement et la conduite des opérations d\'armement. Néanmoins, lorsque la dimension (enjeu, périmètre, coût...) du système d\'information ne nécessite pas de suivre le détail des phases du système, il pourra être décidé par les commissions de regrouper certains examens.

Les différentes phases de la vie d\'un système sont :

  • initialisation (première expression du besoin fonctionnel) ;
  • orientation (stabilisation du besoin en termes de fonctions, performance, soutien, sécurité, interopérabilité...) ;
  • élaboration (finalisation des conditions de réalisation) ;
  • réalisation (phase se terminant à l\'issue de la vérification de service régulier) ;
  • utilisation (phase de service opérationnel) ;
  • retrait de service du système.

Pour les SIAG, si les coûts constatés par la DGSIC (1) varient de 10 p. 100 en plus ou en moins par rapport aux ressources (budgétaires ou humaines) prévues lors d\'un précédent examen, le système doit systématiquement faire l\'objet d\'un nouvel examen.

Toute évolution majeure ou refonte technique d\'un système est considérée comme un nouveau projet qui fera également l\'objet d\'un examen pour validation de cette évolution.

Sont également examinés sur convocation du COVESIOC, les opérations, systèmes et projets entrant dans le plan de rationalisation général.

3.2. Attendus.

L\'examen du dossier à chaque jalon doit permettre de vérifier et de justifier :

  • la conformité du projet aux schémas directeurs ou documents d\'orientations et plus particulièrement la conformité du projet au volet opérationnel du schéma directeur de la zone fonctionnelle concernée. Pour les SIOC, la conformité et la cohérence par rapport à l\'objectif directeur des SIOC du ressort OCO/ASF, aux orientations des grands programmes de convergence, à la trajectoire SIA et aux plans de l\' organisation du traité de l\'atlantique nord (OTAN) seront également présentées ;
  • la prise en compte des directives générales et particulières applicables aux différents segments SIC, notamment celles concernant la sécurité, l\'architecture technique, l\'administration des données et les directives issues de la DGSIC ;
  • l\'inscription du projet dans la démarche de rationalisation (rejointe d\'un socle technique et applicatif, notamment) et la prise en compte du projet dans tous ses aspects (équipements, soutien, personnel, doctrine, infrastructure (1) ,...);
  • son positionnement sur le plan d\'occupation des sols du ministère et son positionnement par rapport aux systèmes connexes connus ;
  • la capacité de la DIRISI (2) sur les plans des ressources humaines, techniques et financières, à prendre en charge l\'hébergement et l\'exploitation technique du système, ainsi que selon le cas, le suivi des marchés de maintien en condition opérationnelle (MCO) qui lui sont confiés et la mise en œuvre du soutien SIC et de la sécurité. Pour les SIOC, selon le cas, la capacité des armées, services et directions à déployer, mettre en œuvre et soutenir les systèmes considérés ;
  • l\'existence et la conformité de la démarche de sécurisation ;
  • l\'existence et la qualité du plan de management ;
  • l\'évolution du calendrier du projet (diagramme temps/temps par exemple) ainsi que celle de son devis financier et de son coût ;
  • la faisabilité financière et/ou la capacité de réalisation dans les centres de développement ;
  • la charge indirecte supportée par l\'infrastructure informatique du ministère exploitée par la DIRISI consécutive au besoin d\'interconnexion et d\'interopérabilité entre systèmes.

L\'annexe I. précise les attendus spécifiques en fonction des jalons.

3.3. Planification des travaux des commissions.

La commission concernée fixe annuellement, ou semestriellement pour les SIOC, la liste des systèmes qui devront faire l\'objet d\'un examen. Tout projet apparaissant en cours d\'année et n\'ayant pas été identifié lors de la revue annuelle devra faire l\'objet d\'un examen.

Un calendrier prévisionnel annuel, ou semestriel pour les SIOC, relatif à l\'examen des systèmes, est réalisé en concertation avec les responsables de zones fonctionnelles, états-majors, directions et services. La DGSIC, qui est rendue destinataire des programmations, peut demander à tout moment à faire inscrire l\'examen d\'un système particulier.

Il appartient aux états-majors, directions et services d\'indiquer au plus tôt à la commission concernée, en vue de leur inscription sur la liste mentionnée ci-dessus, les systèmes ou projets nouveaux non répertoriés.

4. ORGANISATION DES GROUPES DE TRAVAIL SPECIALISÉS.

Afin d\'organiser l\'instruction des dossiers et de préparer leurs décisions formelles, chaque commission dispose d\'un groupe de travail spécialisé ;

  • dans l\'examen des projets (GTEP) pour les SIAG ;
  • d\'instruction des systèmes (GIS) pour les SIOC.

4.1. Composition.

Pour les SIAG, le GTEP est présidé par le sous-directeur de la maîtrise des applications de la DGSIC.

Pour les SIOC, le GIS est coprésidé par DGA/DO/UMESIO/DSM Terre et interarmées et EMA/EPI/OCIA.

Ils comprennent les membres permanents suivants :

  • représentants de l\'état-major des armées (SC soutien pour les SIAG, EMP pour les SIOC) ;
  • représentants de la direction générale de l\'armement (SMQ/SDSI pour les SIAG, DO/UMESIO pour les SIOC) ;
  • un représentant du secrétariat général pour l\'administration (SGA) ;
  • un représentant de chaque état-major d\'armée [état-major de l\'armée de terre (EMAT), état-major de la marine (EMM) et état-major de l\'armée de l\'air (EMAA) ] ;
  • un représentant de la direction centrale du service du commissariat des armées (DCSCA) ;
  • un représentant de la direction centrale du service de santé des armées (DCSSA) ;
  • un représentant de la direction centrale du service des essences des armées (DCSEA) ;
  • un représentant de la direction interarmées des réseaux d\'infrastructure et des systèmes d\'information (DIRISI) ;
  • un représentant de la direction générale des systèmes d\'information et de communication (pour les SIOC) ;
  • un représentant de chacune des autres commissions, à titre consultatif ;
  • la présidence de chacun des sous-comités du comité directeur (CODIR) des intranets ou son représentant ;
  • le responsable de la zone fonctionnelle concernée pour chaque sujet ou son représentant ;
  • un représentant du CIADIOS ;
  • un représentant de la direction du renseignement militaire (pour les SIOC) ;
  • un représentant de l\'EDPI SIA (pour les SIOC).

En tant que de besoin, la présidence du groupe de travail (GTEP ou GIS) peut associer toute personne présentant une expertise en rapport avec le projet examiné, notamment en provenance des unités de management de la DGA.

Le contrôle général des armées est tenu informé de l\'ordre du jour et se fait représenter quand il le juge nécessaire.

4.2. Secrétariat.

Les réunions des groupes de travail spécialisés sont organisées par segments d\'informatique (SIOC, SIAG, IST), l\'ordre du jour et l\'organisation étant à la charge de leur propre secrétariat.

Le secrétariat des groupes de travail spécialisés est assuré par la DGSIC pour les SIAG et par le CIADIOS pour les SIOC. La liste nominative des représentants est entretenue par les secrétariats respectifs. Il existe un secrétariat permanent du GIS (SP GIS) qui organise des pré-revues des systèmes et projets en liaison avec les armées, les services et directions.

La présidence des groupes de travail spécialisés décide des modalités d\'examen des systèmes : examen formel, avec présentation par les référents désignés (maître d\'ouvrage pour les SIAG), examen sur dossier avec présentation du système ou du projet par le responsable de la zone fonctionnelle, ou examen dématérialisé.

5. FONCTIONNEMENT DES GROUPES DE TRAVAIL SPÉCIALISÉS.

5.1. Planification.

Les groupes de travail spécialisés se réunissent périodiquement, en principe vingt fois par an, selon des calendriers établis en fin d\'année pour toute l\'année suivante (pour le semestre suivant pour les SIOC). Ces calendriers sont actualisés si nécessaire.

La procédure relative à l\'examen des projets débute dès le stade d\'initialisation. À ce stade, la maîtrise d\'ouvrage (MOA) doit consulter le responsable de la zone fonctionnelle concernée, l\'autorité qualifiée dont dépend la MOA, la DIRISI et les organismes en charge de l\'urbanisation, et le sous-comité architecture et services du CODIR des intranets. Elle doit obtenir leurs avis avant toute validation par le responsable de l\'organisme demandeur (EMA, DGA, SGA, EMAT, EMM, EMAA, DCSSA, DCSEA, DPSD, DGSE, DICoD, DIRISI, DRM, DGSIC). Pour les systèmes de communication concernés, l\'avis du pilotage unifié DESCARTES-INCAS-Desserte sera demandé. Les procédures de validation internes à chaque organisme sont libres et ne font pas l\'objet de la présente instruction.

La saisine formelle des groupes de travail spécialisés peut intervenir :

  • à l\'initiative des responsables d\'état-major, direction ou service membres du groupe de travail spécialisé ;
  • à l\'initiative de la présidence d\'un sous-comité du CODIR des intranets ;
  • à l\'initiative de la présidence du GTEP ou du GIS, du secrétariat permanent du GIS ou des coprésidents du COVESIOC ;
  • dans tous les cas dès la validation du projet par le responsable de zone fonctionnelle.

Les GTEP et GIS peuvent se réunir en séances communes en vue de statuer sur des projets dont l\'intérêt est général. Ils coordonnent, pour ce faire, leurs calendriers et leurs plans de charge.

5.2. Modalités relatives à l'ordre du jour.

Les différents acteurs des groupes de travail spécialisés instruisent les dossiers dans un délai de vingt jours à compter de la réception de ces dossiers. En cas de dossier non conforme ou d\'arrivée du dossier trop tardive (moins de dix jours ouvrés avant la séance prévue), le secrétariat du groupe de travail concerné décide d\'un complément d\'information et la procédure de validation par l\'organisme concerné est relancée.

Le secrétariat du groupe de travail spécialisé déclenche la procédure d\'examen si le dossier est en conformité avec la présente instruction, en particulier sur les attendus de chaque jalon (décrits en annexe I.). Il assure sa mise en ligne sur l\'intranet défense dans les plus brefs délais, informe les membres du groupe de travail spécialisé et leur adresse l\'ordre du jour de façon dématérialisée.

Si le financement du projet relève d\'une activité réservée, le dossier doit recueillir l\'avis du groupe de travail spécialisé avant d\'être transmis pour approbation à la commission exécutive permanente (CEP).

Le sous-comité architecture et services du CODIR des intranets est systématiquement consulté pour donner un avis technique sur tous les projets présentés. Toutefois, dans le cas où un projet s\'inscrit majoritairement dans la ZF « échanges », le sous-comité peut décider de mener une instruction particulière du sujet. De fait, le passage du projet dans le groupe de travail spécialisé dont il relève sera différé, et éventuellement requalifié en « passage sur dossier » avec présentation par le RZF de la zone « échanges ».

5.3. Modalités relatives au dossier préparatoire.

Afin d\'assurer le pilotage et la gestion du portefeuille des SIC et dans un souci de cohérence et de rationalisation des outils de gouvernance, le ministère de la défense s\'appuie sur un outil de pilotage et de suivi des systèmes d\'information et de communication unique pour le ministère et accessible par l\'intranet défense.

Le dossier de présentation à l\'examen est dématérialisé dans cet outil. Il est composé de la fiche descriptive du système et des documents les plus significatifs, notamment les documents relatifs aux systèmes conçus dans le cadre d\'opérations d\'armement, afin d\'éviter tout travail redondant.

Tous les paragraphes nécessaires à l\'instruction du dossier sont à renseigner dans cet outil avec la plus grande attention conformément à la présente instruction et aux directives de rédaction des fiches système.

Afin de garantir la gouvernance des SIC, les responsables des systèmes doivent tenir à jour régulièrement les informations relatives à leurs systèmes. Pour les systèmes déployés dans plusieurs organismes, il ne sera réalisé qu\'une seule fiche. L\'organisme pilote du système est responsable de sa rédaction et de sa mise à jour.

En liaison avec les différentes entités responsables en la matière, le secrétariat permanent du GIS s\'attache à constituer le référentiel documentaire, fonctionnel, technique et financier de l\'ensemble des SIOC, en service ou à venir. Il réalise au besoin des pré-instructions en liaison directe avec les responsables du système. Pour les SIAG, cette mission est effectuée par la sous-direction de la maîtrise des applications de la DGSIC.

5.4. Déroulement de la séance.

Pour un examen formel, le sujet dispose d\'une heure pour les SIOC (trente minutes de présentation sans interruptions ni commentaires, et trente minutes de débat) et de trente minutes pour les SIAG (quinze minutes pour la présentation et quinze minutes de débat). La présentation devra suivre le canevas figurant en annexe II.

Pour un examen sur dossier, la présence de la maîtrise d\'ouvrage n\'est pas requise, le responsable de la zone fonctionnelle concernée confirme en séance la prise en compte du projet dans la cartographie de la zone fonctionnelle dont il est responsable, le représentant de l\'organisme demandeur pouvant répondre aux éventuelles questions. Les débats relatifs à l\'examen des projets sur dossier doivent être limités au strict minimum. Dans le cas contraire le dossier sera inscrit en examen formel.

L\'examen dématérialisé ne concerne que les projets en phase d\'utilisation stabilisée. Il permet d\'alléger l\'ordre du jour des séances des groupes spécialisés. Les avis requis sont les mêmes que pour les autres examens, mais ils sont portés de façon dématérialisée, y compris l\'avis final du groupe de travail spécialisé. Un compte rendu des avis dématérialisés sera présenté lors de la séance immédiatement postérieure. Pour les SIOC, ces examens sont conduits par le SP GIS.

Les avis des groupes de travail spécialisés, l\'avis ou la décision de la commission, s\'il est requis et les remarques des membres du groupe lors de l\'instruction du dossier sont consultables dans l\'outil de pilotage et de suivi des SIC.

5.5. Modalités de prise de décision.

Pour les SIAG, si le GTEP donne un avis favorable de manière unanime, cet avis vaut décision d\'approbation par la commission. Dans le cas contraire le dossier est soumis pour décision à la réunion de la commission immédiatement postérieure à l\'examen en GTEP.

Pour les SIOC, le GIS fait instruire les dossiers et formule un avis sur le système présenté. Si le sujet est validé en GIS, la coprésidence peut décider d\'une présentation en COVESIOC ; dans le cas contraire, le GIS rend l\'avis et/ou décide pour le compte du COVESIOC, auquel il est rendu compte.

Si le sujet n\'est pas validé en GIS, celui-ci peut :

  • demander une instruction complémentaire et un nouvel examen ;
  • statuer que le sujet ne présente pas d\'enjeu de convergence ;
  • exceptionnellement, présenter le projet en COVESIOC pour arbitrage.

5.6. Modalités relatives au compte rendu.

À l\'issue de chaque réunion, un compte rendu est préparé par le secrétariat et approuvé par la présidence. Il est diffusé aux membres des groupes de travail spécialisés avec copie aux autres participants de façon dématérialisée et au plus tard deux semaines après la réunion. Il est également mis en ligne sur l\'intradef.

5.7. Suivi des actions.

Un relevé des réserves et décisions émises par les groupes de travail spécialisés est annexé au compte-rendu. Leur suivi peut prendre la forme d\'un « reporting » ou d\'une présentation orale en réunion. L\'ensemble du dossier (présentations, fiches descriptives générées par l\'outil de gestion de portefeuille, compte-rendu et suivi des actions) est consultable sur l\'intradef.

6. EFFICACITÉ, ÉVALUATION, AMÉLIORATION.

L\'efficacité des groupes de travail spécialisé est évaluée tous les deux ans par une enquête de satisfaction auprès des membres, des responsables informatiques (maîtrises d\'ouvrage, directeurs de projets, chefs de projet).

La nécessité de l\'amélioration du fonctionnement des groupes de travail spécialisés est examinée annuellement.

Cette instruction annule et remplace l\'instruction n° 1025/DEF/SGA du 2 août 2007 fixant les modalités de présentation des projets de système d\'information et de gestion à l\'avis de la commission des systèmes d\'information d\'administration et de gestion (CSIAG).

Pour le ministre de la défense et par délégation :

Le directeur général des systèmes d'information et de communication,

Christian PÉNILLARD.

Annexes

Annexe I. Attendus de chaque jalon (éléments à insérer dans la fiche descriptive dans l'outil de gestion de portefeuille et à présenter lors de l'examen).

Premier jalon, après la première expression du besoin fonctionnel [objectif d\'état-major (OEM), cahier des charges fonctionnel (CDCF) ou fiche d\'expression de besoins (FEB)] :

  • l\'étude d\'opportunité réalisée en concertation avec le responsable de la zone fonctionnelle concernée (processus instrumentés, référence au plan d\'occupation des sols) ;
  • le besoin fonctionnel, l\'analyse et la description des processus à instrumenter ;
  • les besoins en interopérabilité et une première identification des acteurs concernés ;
  • l\'avis formel du responsable de la zone fonctionnelle concernée ;
  • le périmètre envisagé de déploiement, les besoins en capillarité ;
  • l\'étude des besoins ou solutions similaires (au ministère de la défense ou en dehors) ;
  • le cas échéant, le besoin d\'étude de définition ou de faisabilité, ou le besoin d\'assistance à maîtrise d\'ouvrage ;
  • les avantages et inconvénients de la démarche, notamment en termes de mutualisation de solution et/ou d\'arrêt d\'autre(s) système(s), de coûts ou de complexité supplémentaires induits ;
  • une première analyse des menaces et les dispositions envisagées pour les contrer ;
  • la désignation d\'un responsable de la sécurité des systèmes d\'information (SSI) pour le projet ;
  • la sensibilité des informations manipulées et des fonctions en termes de confidentialité, intégrité, disponibilité, opportunité d\'une homologation de sécurité (avec décision de l\'autorité qualifiée), fiche d\'expression rationnelle des objectifs de sécurité (FEROS) ;
  • l\'initialisation de la fiche de l\'application du tableau de bord des homologations SSI ;
  • les réseaux dont l\'utilisation est envisagée ;
  • l\'opportunité d\'une déclaration à la CNIL ;
  • une première estimation du coût global et des délais. Calendrier prévisionnel et principales phases du projet avec, si possible, une première estimation des ressources humaines et financières nécessaires ;
  • la fiche d\'expression de besoin transmise à la DIRISI ;
  • le cas échéant, la demande d\'achat transmise au représentant du pouvoir adjudicateur ;
  • les besoins connexes éventuels : infrastructure, soutien, concept, doctrine ;
  • une première analyse des risques internes et externes du projet.

Deuxième jalon, après stabilisation du besoin et avant la publication de l\'appel d\'offres, le cas échéant :

  • la fiche de caractéristique militaire (FCM) pour les opérations d\'armement, et pour les autres types de projet, le cahier des clauses techniques particulières (incluant la structuration du marché) ou le document équivalent dans le cas d\'un développement interne ;
  • les relations précises avec d\'autres systèmes d\'information et avec le système de communication ;
  • l\'avis formel des sous-comités « architecture et services » et  « sécurité des systèmes d\'information (1) » du comité de gouvernance des intranets, dans le cas des services intranets et réseaux télécom ;
  • la réalité de la prise en compte des directives générales et particulières applicables aux différents segments SIC, notamment celles concernant la sécurité, l\'architecture technique, l\'administration des données et les directives issues de la DGSIC ;
  • la contribution à la convergence des systèmes et l\'intégration au STC-IA ;
  • les prévisions des consommations de ressources humaines et financières, avec le découpage détaillé du projet par année et par phase (orientation, élaboration, réalisation, utilisation, retrait de service du système) ;
  • l\'étude économique a priori, y compris les gains attendus (retour sur investissement), que la dépense soit un coût budgétaire ou un coût en ressources humaines ;
  • l\'avis de la DIRISI et/ou des armées, services ou directions relatif à l\'éligibilité à la prise en charge ;
  • le point sur les besoins connexes : infrastructure, soutien, concept, doctrine ;
  • le plan de management, avec l\'organisation et le rôle des instances de conduite du projet (comité directeur, comité de pilotage, groupes de travail, etc.) ;
  • les dispositions concourant à la sécurité du système d\'information et au maintien en condition de sécurité, sont la stratégie d\'homologation si requis et la demande d\'audit ;
  • les modalités du déploiement et de conduite du changement ;
  • l\'architecture technique d\'ensemble, décrivant les grands composants ;
  • les modalités de reprise des données.

Troisième jalon, en phase de notification du contrat de réalisation ou avant le début des travaux de réalisation en interne :

  • les thèmes du deuxième jalon qui ont évolué, notamment reprendre les points suivants :
    • l\'avis formel des sous-comités « architecture et services » et  « sécurité des systèmes d\'information » du comité de gouvernance des intranets, dans le cas des services intranets et réseaux télécom ;
    • la réalité de la prise en compte des directives générales et particulières applicables aux différents segments SIC, notamment celles concernant la sécurité, l\'architecture technique, l\'administration des données et les directives issues de la DGSIC ;
    • la contribution à la convergence des systèmes et l\'intégration au STC-IA ;
  • la STBr (2) et les éléments du DLR (3) pour les programmes d\'armement ;
  • la solution retenue pour la réalisation du système (offre de l\'industriel et acte d\'engagement ou spécifications techniques pour une réalisation en interne) ;
  • le cahier des clauses administratives particulières (structuration du marché) ;
  • la mise à jour de l\'étude économique et du coût du projet ;
  • la structuration du marché de réalisation et de soutien (au regard de l\'offre retenue) ;
  • les éléments permettant de maîtriser les risques internes et externes ;
  • l\'engagement de la DIRISI ou de l\'organisme prenant en charge l\'hébergement et l\'exploitation du système ;
  • le calendrier détaillé des opérations menant à la dernière vérification de service régulier (VSR) ;
  • le calendrier estimatif des opérations jusqu\'au retrait de service ;
  • le projet de mise en service opérationnel ;
  • le concept et doctrine d\'emploi ;
  • le plan soutien logistique intégré ;
  • le besoin en équipement de sécurité ;
  • le plan de continuité informatique, plan de reprise informatique, avis de l\'autorité de régulation.

Quatrième jalon, en fin de période de VSR ou avant la notification des tranches conditionnelles relatives au soutien ou avant tout événement modifiant le cadre de réalisation fixé (avenant ou marché complémentaire) :

  • le compte-rendu d\'exécution de la phase de réalisation, mentionnant les difficultés rencontrées et les solutions adoptées ;
  • l\'avenant ou le marché complémentaire ;
  • les arguments relatifs à l\'affermissement ou non de la première tranche de soutien ou à tout événement modifiant l\'exécution du marché ;
  • la mise à jour du plan de management ;
  • la mise à jour de l\'étude économique, le bilan du coût de réalisation du projet (en ressources internes et/ou coûts d\'investissement et de fonctionnement) ;
  • le dossier d\'homologation (dont la décision d\'homologation), si requis ;
  • si le système ne fait pas l\'objet d\'une démarche d\'homologation, une déclaration de l\'autorité qualifiée indiquant que les besoins de sécurité sont couverts par la solution retenue et que le système n\'augmente pas les risques sur les réseaux utilisés et sur les autres systèmes les utilisant déjà ;
  • les procédures d\'exploitation de sécurité (PES).

Cinquième jalon, avant l\'affermissement de tranches conditionnelles ou le renouvellement de marchés relatifs au soutien en utilisation, ou la réalisation d\'évolutions majeures (4) :

  • les appréciations des utilisateurs et des équipes de soutien sur les fonctionnalités utilisées/non utilisées ;
  • les évolutions significatives envisagées décrivant notamment les nouveaux éléments d\'architecture ;
  • les arguments relatifs à l\'affermissement ou non des tranches conditionnelles de soutien ; ou à tout événement modifiant l\'exécution du marché ;
  • la mise à jour de l\'étude économique et le coût du soutien ;
  • la mise à jour du plan de management ;
  • la tenue à jour du dossier de sécurité ;
  • les thèmes du deuxième jalon qui ont évolué, notamment reprendre les points suivants :
    • l\'avis formel des sous-comités « architecture et services » et « sécurité des systèmes d\'information » du comité de gouvernance des intranets, dans le cas des services intranets et réseaux télécom ;
    • la réalité de la prise en compte des directives générales et particulières applicables aux différents segments SIC, notamment celles concernant la sécurité, l\'architecture technique, l\'administration des données et les directives issues de la DGSIC ;
    • la contribution à la convergence des systèmes et l\'intégration au STC-IA ;
  • le cahier des clauses techniques particulières de l\'évolution ou le document équivalent dans le cas d\'un développement interne.

Sixième jalon, en début de phase de retrait de service :

  • bilan de retrait de service, explicitant la procédure retenue pour le retrait physique de l\'application du ou des serveurs sur lesquels elle est installée (reprises des données et des fonctionnalités, mise à disposition en lecture pendant une durée définie...) ;
  • les modalités de destruction des données et des supports de masse, y compris les sauvegardes ;
  • les modalités de retraits des règles particulières créées à la mise en place de l\'application (ouverture de flux, paramétrages d\'équipements réseaux ou de sécurité, comptes divers, adresses fonctionnelles, etc.).

Le procès-verbal de retrait physique de l\'application sera transmis à la commission concernée par l\'organisme chargé de l\'hébergement du système à l\'issue de la phase de retrait de service. Il ne fera pas l\'objet d\'une présentation.

Pour les opérations d\'armement qui suivent des processus connus, maîtrisés et documentés par ailleurs, les éléments demandés au passage des différents jalons seront adaptés pour rester cohérents avec ces processus.

Notes

    Par l\'intermédiaire du GT SSI.1Spécification technique de besoin de référence.2Dossier de lancement de réalisation.3En particulier, sont considérées comme des évolutions majeures : - un ajout significatif de fonctionnalités ; - une refonte technologique ou une évolution significative d\'architecture ; - un changement de la confidentialité, intégrité, disponibilité des données ou des fonctions du SI ; - l\'ajout, la modification ou la suppression de fonctions ou d\'équipements de sécurité ; - une modification à la baisse de l\'agrément ou de la qualification d\'un équipement de sécurité ; - la modification de la stratégie d\'homologation ; - une évolution des interconnexions ou une extension à des utilisateurs hors ministère. 4

Annexe II. Plan de la présentation.

Dossier de présentation et d\'analyse des projets et systèmes

Ce plan doit être adapté au jalon auquel le projet est présenté.

Chaque item fait l\'objet d\'une seule diapositive. Les éléments listés ci-dessous doivent figurer dans la fiche descriptive dans l\'outil de gestion de portefeuille et pourront être exposés oralement lors de l\'examen.

Présentation générale.

- intitulé ;

- contexte ;

- enjeux ;

- environnement.

Structure de projet/système.

- maîtrise d\'ouvrage/d\'œuvre ;

- organisation, description des instances de direction et de pilotage, RSSI ;

- acteurs, clients, industriels :

- nominatif et coordonnées pour les points de contact du projet.

Eléments de calendrier.

- description des grandes étapes (début des études, CCF, lancement, VSR, MSO et fin de vie du système, etc.) ;

- jalons structurants du projet ou système :

- jalon comité (COPREP, CODIR, COPIL, etc.) ;

- commission (commission contrat, CEP, etc.).

- avancement du projet :

- OEM, FEB, FCM, CCTP...;

- contrats passés, en cours et à venir ;

- stade en cours au titre de la 1516.

Couverture fonctionnelle.

Fonctionnalités offertes :

- décomposition précise sur le plan d\'occupation des sols ;

- référence à un schéma directeur ou à un document structurant ;

- cohérence fonctionnelle et applicative : état des lieux des quartiers adressés par le projet/système, et trajectoire éventuellement prévue par le RZF.

Fonctionnalités réellement utilisées :

- retour des utilisateurs et des équipes de soutien, classement par utilité/satisfaction des fonctionnalités les unes par rapport aux autres ;

- pour quels motifs les fonctionnalités jugées les plus utiles/utilisées le sont-elles ?

- pour quels motifs les fonctionnalités jugées les moins utiles/utilisées le sont-elles ?

 

Exigences fonctionnelles.

Niveau de disponibilité souhaité/statut donné par l\'autorité de régulation.

Sensibilité des informations manipulées.

Procédure d\'homologation, état des documents afférents.

Niveau d\'interopérabilité souhaité et identification précise des acteurs concernés, identification précise des messages formatés utilisés/échangés et justifications d\'éventuelles modifications du référentiel (en liaison avec le système tiers).

Capillarité.

Périmètre de déploiement, identification précise des usagers, localisation géographique et physique des composants du système.

Divers (administration, ergonomie - formation, performances, archivage électronique, etc.).

Architecture physique.

Schéma d\'architecture d\'ensemble décrivant le périmètre et montrant les choix faits, du réseau de transport à l\'application, en passant par les services communs. Identification précise des flux et des ports utilisés.

Environnement du projet : 

- interfaces (IGC notamment) ;

- adhérences éventuelles.

Descriptions : 

- COTS et développement, licencing (propriété et maîtrise des développements/licences libératoires, imputation sur contrat-cadre, etc) : argumentation, analyse avantages/inconvénients sur les aspects coûts, calendaires, fonctionnels, risques, cohérence (STC-IA entre autres), etc ;

- serveurs (systèmes d\'exploitation, BDD, progiciels de gestion, serveurs d\'applications, etc.), nombre, localisation et positionnement par rapport aux SHEM ;

- clients (configuration de base et typologie des clients, particularités logicielles, SSI, etc.), nombre, localisation ;

- contraintes éventuelles sur matériel (banalisation GAIA ou pas, etc.), sur les interfaces (STANAGS, RFC, etc) ;
 

- politique des données et conformité avec le JC3IEDM le cas échéant ;
 

- description précise de l\'architecture de sécurité (sauvegarde, continuité de service, crypto, etc.).

Hébergement/Exploitation/Soutien.

Hébergement : interne ou externe.

Exploitation :

- fonctionnement de l\'administration/gestion/supervision du projet ou du système. Retours sur expérience, taux de satisfaction.

- localisation et armement des centres d\'administration ;

- formation des administrateurs et des usagers ;

- documentations (existence et mise à jour) :

- document d\'exploitation et d\'administration (dont les dossiers de site) ;

- documentation usager (guide, documents de formation, etc.) ;

- documentation d\'architecture et de développement ;

- tout ou partie de ces documents sont-ils la propriété de l\'État, l\'État peut-il les transmettre à un tiers?

Soutien :

- type de soutien (interne, externe, prestations/services, etc) et mode de fonctionnement (hot-line, ticket, etc.) ;

- MCO contractualisé et à venir ;

- organisation de la gestion de configuration ;

- maintien en condition de sécurité : contrat, organisation, fonctionnement ;

- retours sur expérience, taux de satisfaction, état des faits techniques en cours (détails des bloquants et nombre/ancienneté des majeurs et mineurs).

Eléments physico-financiers.

- tableau récapitulatif du financement sur les années précédentes et à venir, coût global estimé ;

- besoin de financement en AE/CP, BOP concerné ;

- En fonction des stades 1516 (initialisation, orientation, élaboration, réalisation, utilisation, retrait du service) ;

- retour sur investissement justifié, prévisible et constaté (selon les phases) ;

- types de prestation (contenus physiques et structuration des actes contractuels) ;

- services concernés par les aspects contractuels.

 

Cohérence et convergence.

- efficience du projet/systèmes au regard des investissements consentis :

- retours sur investissement humain, financiers, techniques ;

- améliorations fonctionnelles majeures.

- élément de rationalisation apportés par le projet/système :

- possibilité de généralisation des services ; 

- cohérence avec le STC-IA et intégration dans la démarche SIA.

- trajectoire de convergence envisagée :

- planning des principaux jalons de convergence ;

- actes contractuels afférents.

- positionnement sur le POS ;

- liens avec les systèmes connexes ;

- opportunités de généralisation.

Dernier passage en (date et résultats - énoncé des décisions et recommandations).

- SC « architecture et services » du CODIR des intranets, dans le cas des services intranets et réseaux télécom ;

- SC « sécurité des systèmes d\'information » du CODIR des intranets, dans le cas des services intranets et réseaux télécom ;

- GIS/GTEP ;

- COVESIOC ;

- CEP ;

- autorité de régulation.