> Télécharger au format PDF
Archivé SECRETARIAT GENERAL POUR L'ADMINISTRATION :

INSTRUCTION N° 1025/DEF/SGA fixant les modalités de présentation des projets de systèmes d'information, d'administration et de gestion à l'avis de la commission des systèmes d'information, d'administration et de gestion.

Abrogé le 22 juillet 2010 par : INSTRUCTION N° 2005/DEF/DGSIC relative aux modalités d'examen des systèmes d'information et de communication. Du 02 août 2007
NOR D E F P 0 7 5 1 5 8 2 J

Autre(s) version(s) :

 

Précédent modificatif :  Décret N° 2008-382 du 21 avril 2008 relatif aux emplois d'expert de haut niveau et de directeur de projet des administrations de l'État et de ses établissements publics.

Référence(s) : Arrêté du 06 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.

Pièce(s) jointe(s) :     Une annexe

Texte(s) abrogé(s) :

Instruction n° 713/DEF/SGA du 24 juin 2004 (n.i. BO).

Classement dans l'édition méthodique : BOEM  160.1.

Référence de publication : BOC N°22 du 13 septembre 2007, texte 1.

1. Objet.

L'article 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, stipule que la commission des systèmes d'information d'administration et de gestion (CSIAG) examine et approuve les projets des états-majors, directions et services selon des modalités définies par une instruction particulière. Le présent document constitue cette instruction.

2. Domaine d'application.

Tout projet relevant d'un système d'information appartenant aux domaines métiers définis par la CSIAG, quels que soient le montant et le mode de financement, doit recevoir l'approbation de cette commission, selon des modalités définies au point 4 ci-dessous.

La présente instruction ne prend pas en compte les systèmes relevant de l'informatique scientifique et technique (IST) ni les systèmes d'information opérationnels et de communication (SIOC). Pour la gendarmerie nationale, elle s'applique dans les limites compatibles avec la spécificité « sécurité intérieure » de ses systèmes d'information.

3. Attendus de l'examen des projets.

L\'examen des projets par la CSIAG se produit à l\'occasion des principaux jalons, selon les modalités détaillées au point 4 de la présente instruction :

  • un premier jalon, après l\'expression du besoin fonctionnel, dès la fin de l\'étude d\'opportunité et avant la préparation de tout contrat ;

  • un deuxième jalon juste avant la notification du marché de réalisation ;

  • un troisième jalon pour l\'affermissement d\'éventuelles tranches conditionnelles ;

  • un quatrième jalon pour le bilan de fin de projet dès que la dernière vérification de service régulier (VSR) du marché de réalisation est prononcée.

L\'examen du dossier doit permettre de vérifier :

  • la faisabilité financière ;

  • la conformité du projet au schéma directeur des SIAG et plus particulièrement la conformité du projet au volet opérationnel du domaine métier concerné ;

  • la prise en compte des directives de la direction générale des systèmes d\'information et de communication (DGSIC) ;

  • le cas échéant, les capacités de la direction interarmées des réseaux d\'infrastructure et des systèmes d\'information (DIRISI) pour supporter la mise en œuvre du nouveau système, sur les plans des ressources humaines, techniques et financières.

Plus précisément, seront présentés les éléments suivants :

Pour le premier jalon :

  • l\'étude d\'opportunité réalisée en concertation avec le responsable du domaine métier concerné (processus instrumentés, référence au plan d\'occupation des sols) ;

  • l\'étude des besoins ou solutions similaires (au ministère de la défense ou en dehors) ;

  • les avantages attendus dont la mutualisation de solution et l\'arrêt d\'autre(s) système(s) ;

  • un découpage par phase (a minima études, réalisation, exploitation) avec une première estimation des ressources humaines et financières ;

  • l\'avis du responsable du domaine métier concerné ;

  • les dispositions concourant à la sécurité du système d\'information (intégrité, disponibilité, confidentialité du système et des données) ;

  • l\'opportunité d\'une homologation de sécurité ;

  • l\'analyse des risques internes et externes ;

  • l\'avis de la DIRISI relatif à l\'éligibilité du système d\'information (SI) , la charge d\'exploitation, la qualité de service, etc. ;

  • l\'engagement du respect des normes et standards validés par la DGSIC.

Pour le deuxième jalon, outre une mise à jour des points précédents :

  • l\'étude économique, y compris les gains attendus (retour sur investissement) ;

  • les fonctionnalités, par notamment l\'analyse des processus ;

  • les relations avec d\'autres SI, ainsi qu\'avec le système de communication ;

  • la prise en compte réelle des normes et des standards validés par la DGSIC ;

  • les prévisions des consommations de ressources humaines et financières(1), avec le découpage détaillé du projet par année et par phase (études, réalisation, exploitation et retrait de service), consommatrices de ressources humaines et financières ;

  • le management, avec l\'organisation des instances de conduite du projet (comité directeur, comité de pilotage, groupes de travail, etc.) ;

  • la désignation d\'un responsable de la sécurité du système d\'information (RSSI), à temps plein ou pas ;

  • les modalités du déploiement et de conduite du changement ;

  • les modalités de reprise des données.

Pour le troisième jalon, dans le cas d\'un marché à tranches, outre la mise à jour des points précédents :

  • les résultats de la tranche ferme ;

  • les arguments relatifs à l\'affermissement ou non de la ou des tranches conditionnelles ;

  • la rédaction des procédures d\'exploitation de sécurité (PES).

Pour le quatrième jalon, outre la mise à jour des points précédents, le compte rendu de fin de projet qui mentionnera clairement :

  • la date de la dernière VSR du marché de réalisation ;

  • un récapitulatif de l\'exécution du ou des marchés ;

  • le coût réel du projet à l\'issue de la dernière VSR [(hors coûts de maintien en condition opérationnelle (MCO), tierce maintenance applicative (TMA) et ressources humaines)] ;

  • un bilan économique arrêté à la fin de la réalisation ;

  • la rédaction des PES au cas où ils ne seraient pas disponibles pour le troisième jalon.

4. Modalités d'examen des projets.

La CSIAG fixe la liste des projets 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, relatif à l\'examen des projets, est réalisé en concertation avec les états-majors, directions et services.

Afin de préparer la décision formelle de la CSIAG, il est créé un groupe de travail spécialisé dans l\'examen des projets (GTEP). Si le GTEP donne un avis favorable de manière unanime, cet avis vaut décision d\'approbation par la CSIAG. Dans le cas d\'un avis défavorable le dossier est soumis pour décision à la réunion de la CSIAG immédiatement postérieure à l\'examen en GTEP.

Toute évolution majeure ou refonte technique d\'un système d\'information est considéré comme une nouveau projet.

Si le dépassement des coûts constatés par rapport au montant accordé par le GTEP est supérieur à 10 p.100 et de plus de 100 kilos euros, le projet doit systématiquement faire l\'objet d\'un nouvel examen.

Il appartient aux états-majors, directions et services d\'indiquer au plus tôt au secrétariat de la CSIAG, en vue de leur inscription sur la liste mentionnée ci-dessus, les projets nouveaux non répertoriés.

La procédure relative à l\'examen des projets est initialisée dès l\'étude d\'opportunité (ou de faisabilité) du projet. La DIRISI et le responsable du domaine métier concerné doivent être consultés par la maîtrise d\'ouvrage et donner leur avis avant toute validation par le responsable de l\'organisme demandeur. Les procédures de validation, internes à chaque organisme, sont libres et ne font pas l\'objet de la présente instruction.

5. Composition du GTEP.

Il comprend les membres permanents suivants :

  • le chef de la mission des systèmes d\'information d\'administration et de gestion du secrétariat général pour l\'administration (SGA/MSIAG), président ;

  • un représentant de la direction générale des systèmes d\'information et de communication ;

  • un représentant de l\'état-major des armées ;

  • un représentant de la délégation générale pour l\'armement ;

  • un représentant du secrétariat général pour l\'administration ;

  • un représentant de chaque état-major d\'armée ;

  • un représentant de la direction générale de la gendarmerie nationale ;

  • un représentant de la direction centrale du service de santé des armées ;

  • un représentant de la direction centrale du service des essences des armées ;

  • un représentant de la délégation à l\'information et la communication de la défense ;

  • un représentant de la délégation aux affaires stratégiques ;

  • un représentant de la direction interarmées des réseaux d\'infrastructure et des systèmes d\'information ;

  • un représentant de la direction générale de la sécurité extérieure ;

  • un représentant de la direction de la protection et de la sécurité de la défense ;

  • un représentant de la commission ministérielle technique des SIC, à titre consultatif ;

  • un représentant de la commission ministérielle de la sécurité des systèmes d\'information, à titre consultatif ;

  • un représentant de la commission des systèmes d\'information opérationnels et de communication, à titre consultatif ;

  • un représentant de la commission de l\'informatique scientifique et technique, à titre consultatif ;

  • le responsable du domaine métier concerné ou son représentant ;

  • toute personne dont la présence est souhaitée par le président du GTEP, présentant une expertise en rapport avec le projet examiné.

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.

Le secrétariat du GTEP est assuré par le bureau de l\'observatoire et du suivi du référentiel des systèmes d\'information d\'administration et de gestion du ministère de la défense (SGA/MSIAG/BOSR).

La liste nominative des représentants est entretenue par le secrétariat du GTEP.

6. Fonctionnement du GTEP.

6.1. Planification.

Le GTEP se réunit périodiquement, au minimum 15 fois par an, selon un calendrier établi en fin d'année pour toute l'année suivante. Il est actualisé en cours d'année si nécessaire.

Le secrétaire du GTEP établit en fin d'année, la liste des projets et applications appartenant aux domaines métiers des SIAG pour l'année suivante et la communique à chaque membre.

Le président du GTEP décide des modalités de présentation des projets : formel, avec présentation du projet par la maîtrise d'ouvrage, ou sur dossier avec présentation du projet par le responsable du domaine métier.

Dans le premier cas la maîtrise d'ouvrage dispose de 30 minutes (15 minutes pour la présentation du projet et 15 minutes pour le débat). Dans le second cas la présence de la maîtrise d'ouvrage n'est pas requise, le responsable du domaine métier concerné confirme en séance la prise en compte du projet dans la cartographie de son domaine, 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.

La saisine formelle du GTEP intervient dès la validation du projet par le responsable de l'état-major, direction ou service membre du GTEP et à son initiative.

La durée de principe de chaque réunion est de trois heures.

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

La mission SIAG instruit les dossiers en liaison avec la DGSIC dans un délai maximum de cinq jours après avoir été saisi par le secrétaire du GTEP. En cas de dossier non conforme, ce délai est suspendu au complément d'information attendu et la procédure de validation par l'organisme concerné est relancée.

Le BOSR déclenche la procédure d'examen si le dossier est en conformité avec la présente instruction. Il assure la mise en ligne sur l'intranet défense (http://siag.sga.defense.gouv.fr) du dossier dans les plus brefs délais, informe les membres du GTEP et adresse une note de convocation qui précise l'ordre du jour.

La réunion du GTEP destinée à émettre un avis sur le projet, doit avoir lieu entre cinq et dix jours ouvrés qui suivent la mise à disposition du dossier à ses membres.

Si le financement du projet relève d'une opération budgétaire d'investissement (OBI) réservée, le dossier doit être approuvé par la CSIAG avant d'être transmis pour approbation à la commission exécutive permanente (CEP).

L'avis du GTEP est mentionné dans la fiche projet, ainsi que l'avis de la CSIAG, s'il est requis. Il est consultable par le contrôle général des armées au titre du contrôle préventif sur les marchés informatiques.


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

Afin d'assurer la gestion des projets de SIAG 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 d'administration et de gestion (OSIAG), disponible sur l'intranet défense : http://osiag.sga.defense.gouv.fr/osiag/.

Le dossier de présentation à la CSIAG est électronique. Il est composé de la fiche de projet et des documents les plus significatifs du projet annexés dans l'onglet prévu à cet effet dans l'OSIAG [dossier d'étude d'opportunité à l'occasion du premier jalon ; Cahier des Clauses Techniques Particulières (CCTP), fiche d'évaluation rationnelle des objectifs de sécurité (FEROS) , etc. pour les autres jalons.]

Tous les paragraphes nécessaires à l'argumentation du projet sont à renseigner avec la plus grande attention conformément aux directives de la présente instruction et aux conseils de rédaction figurants sur la fiche de projet (cf. annexe).

Afin de garantir la gouvernance des SIC, les maîtrises d'ouvrage doivent tenir à jour régulièrement les informations relatives à leur projet (avancement du projet, prévision et consommation des autorisations d'engagement et des crédits de paiement pour la durée de vie du projet). Le responsable d'organisme, membre du GTEP, veille à la mise à jour des fiches OSIAG de son ressort.

Le retrait de service d'une application ne fait pas l'objet d'un examen particulier mais doit être renseigné dans l'outil de pilotage et de suivi des SIAG.

Pour les projets mutualisés(2), il ne sera réalisé qu'une seule fiche OSIAG. L'organisme pilote du projet est responsable de sa rédaction et de sa mise à jour.

Les prises en compte de la saisine du GTEP et les remarques relatives à l'instruction du dossier par la mission SIAG sont consultables par tous les acteurs via l'onglet « Avis GTEP » de l'OSIAG.

Les projets financés en totalité ou en partie par un budget opérationnel de programme (BOP) autre que le BOP 21270C doivent faire l'objet d'un engagement de financement écrit du responsable du BOP concerné.

6.4. Modalités relatives au compte rendu.

À l'issue de chaque réunion du GTEP, un compte rendu est préparé par le secrétaire et approuvé par le président. Il est diffusé au plus tard deux semaines après la réunion aux membres du GTEP avec copie aux autres participants. Il est également mis en ligne sur l'intranet défense (http://siag.sga.defense.gouv.fr).

6.5. Suivi des actions.

Un relevé de réserves émises par le GTEP est annexé à l'ordre du jour. Le suivi peut prendre la forme d'un compte rendu ou d'une présentation orale en réunion.

Le secrétaire du GTEP est chargé de l'alimentation des indicateurs du ressort de la CSIAG demandés par la DGSIC.

7. Éfficacité, évaluation, amélioration.

(Modifié : décret du 21/04/2008)

L\'efficacité du GTEP est évaluée annuellement par une enquête de satisfaction auprès des membres, des responsables informatiques (maîtrises d\'ouvrage, experts de haut niveau ou directeurs de projets, responsables informatiques de sites ayant présenté un projet).

L\'amélioration du fonctionnement du GTEP est examinée annuellement.


8. Texte abrogé.

L'instruction n° 713/DEF/SGA du 24 juin 2004 fixant les modalités de présentation des projets de SIAG à l'avis de la CSIAG est abrogé. 

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

Le secrétaire général pour l'administration,

Christian PIOTRE.

Annexe

Annexe. Consignes de rédaction de la fiche projet. FICHE PROJET OSIAG.

Préambule.

La fiche projet constitue la carte d'identité de tout projet de SIAG.

Chacune de ses sections doit être renseignée avec le plus grand soin en apportant les éléments les plus pertinents, les plus concis et les plus récents disponibles.

Après une première validation par l'organisme pilote cette fiche sera accessible en consultation à l'ensemble des utilisateurs de l'OSIAG et deviendra un document de référence.

Tout type de document électronique peut être annexé à la fiche projet mais il ne dispense en aucun cas le rédacteur de fournir les éléments de synthèse demandés au sein de chacune des section décrite ci dessous.

1. Objectifs.

Il s'agit de présenter l'origine du projet, son contexte, le besoin à satisfaire impliquant les objectifs généraux fixés par la MOA.

2. Description.

2.1. Description fonctionnelle.

Ce paragraphe doit décrire :

  • les processus instrumentés (référence au schéma directeur du ou des métiers concernés ou impactés, positionnement par rapport au plan d\'occupation des sols) ;

  • les référentiels de données utilisés;

  • les grandes fonctionnalités attendues de l\'application ou des applications faisant l\'objet du projet.

Les SI existants permettant de répondre au besoin de la MOA doivent être identifiés en liaison avec le responsable de domaine métier.

2.2. Description technique.

Ce paragraphe doit donner une description technique du projet dans l\'état d\'estimation du moment.

Généralités :

  • type d\'architecture (client léger, lourd, autres) ;

  • progiciel de gestion intégrée utilisé ;

  • outil décisionnel.

Qualité de service :

  • criticité du système, délai de rétablissement du service (critique, H1, H6, H24, H48, etc.) ;

  • bande passante réseau nécessaire en kbits/s (<> kbytes/s) dans le sens client => serveur et serveur => client ;

  • volume des données.

Périmètre de déploiement :

  • nombre de postes de travail concernés ;

  • nombre d\'utilisateurs ;

  • nombre de serveurs concernés ;

  • sites géographiques des serveurs ;

  • nombre de sites clients ;

  • sites géographiques des clients.

Interopérabilités :

  • type d\'annuaire utilisé (propriétaire, LDAP) ;

  • normes et standards mis en œuvre, référentiels employés (RGI, RGS, données, etc.) et justification, le cas échéant, du non respect de ceux-ci ;

  • liste des flux d\'échange identifiés présents ou à venir vers d\'autres systèmes d\'information (sens et nature des flux, protocole d\'échange).

Logiciels mis en œuvre :

  • atelier de génie logiciel ;

  • langage(s) de développement ;

  • système(s) d\'exploitation serveur ;

  • système(s) d\'exploitation client ;

  • système(s) de gestion de base de données utilisé ;

  • serveur Web ou d\'application ;

  • logiciels de sécurité.

Études, développement :

  • les méthodes de conduite de projet et de modélisation (SDMS, MERISE etc.);

  • type d\'ingénierie (développement spécifique, progiciel paramétré, etc.).

Sécurité :

  • niveau de classification du système (joindre la FEROS si elle existe) ;

  • infrastructure de gestion de clés utilisée ;

  • référence de la position de la CNIL relatif au traitement de données nominatives ;

  • position géographique du site de secours ;

  • solution de sauvegarde mise en œuvre ;

  • port utilisé et type de flux (ex: 8080 pour le flux http) ;

  • type de cryptologie ;

  • besoin particulier en infrastructure lié à la sécurité ou au bon fonctionnement du système ;

  • homologation, indiquer si une homologation existe (référence) ou si elle est envisagée (échéance).

3. Avantages et inconvénients.

Ce paragraphe doit décrire les avantages attendus, c'est à dire ce que l'on gagne à réaliser le projet. Indiquer également les inconvénients éventuels liés à la mise en œuvre du projet.

4. Enjeux et risques.

Ce paragraphe doit identifier :

  • les enjeux du projet ;

  • les risques interne au projet ;

  • les risques externes au projet.

 

5. Structures de projet.

5.1. Maîtrise d'ouvrage.

(Modifié: décret du 21/04/2008). 

Ce paragraphe doit décrire l\'organisation du projet : comité directeur, comité de pilotage, groupes de travail, groupes d\'utilisateurs, assistance à maîtrise d\'ouvrage, etc.

Les coordonnées de l\'expert de haut niveau ou directeur de projet, du RSSI ou celles de la direction de projet doivent être renseignées : grade, nom, prénom, numéro de téléphone, adresse de messagerie.

5.2. Maîtrise d'oeuvre.

Présentation succincte de la maîtrise d\'œuvre et des sous-traitants éventuels.

6. Grandes étapes.

Reprendre sommairement mais impérativement le calendrier des étapes significatives du projet avec les dates des principaux jalons (date de notification et des références des marchés, VA et VSR des principales tranches, formations, début du MCO, etc.).

7. Bilan économique.

Les éléments suivants doivent figurer :

  • le coût initial du projet hors MCO, TMA et ressources humaines validé au second jalon de l\'examen des projets par le GTEP ;

  • le coût global du projet validé à l\'occasion du quatrième jalon.

Le retour sur investissement doit être expliqué et si possible estimé de manière chiffrée. Lorsque le projet est déclaré terminé conformément au quatrième jalon, ce paragraphe permet le calcul de l\'indicateur 512 (dépassement du coût initial du projet).

8. Éléments budgétaires.

Ce paragraphe correspond aux financements des différentes phases du projet (études, réalisation, exploitation, retrait). Il convient de renseigner ou de mettre à jour les dates de début et de fin de chaque phase et pour chacune d\'elle de détailler les livrables. Doivent y figurer les activités consommatrices de ressources humaines et financières, année par année, en recherchant l\'estimation la plus précise possible des consommations d\'autorisations d\'engagement (AE) et de crédits de paiement (CP).

Il convient également de renseigner les dépenses engagées et les paiements exécutés pour les années précédant l\'année en cours.

Dans le paragraphe « Commentaires sur les tableaux financiers » il convient de reprendre le contenu physique des consommations d\'AE et de CP réalisées, des projections annuelles d\'AE et de CP consolidées et de préciser en une courte phrase ce qui est demandé au GTEP (tel marché, ou telle tranche pour tel montant).

9. Définition des phases.

ETUDES.

Début : date de début de l\'étude d\'opportunité.

Fin : second jalon de l\'examen des projet par le GTEP.

Description : cette phase regroupe indistinctement toutes les études qu\'elles soient initiales, préalables ou d\'opportunité.

Au sein de cette phase le GTEP statue une première fois, dès la fin de l\'étude d\'opportunité, conformément au premier jalon de l\'examen des projets décrit au paragraphe trois de la présente instruction.

RÉALISATION.

Début : date de notification du marché de réalisation.

Fin : quatrième jalon de l\'examen des projet par le GTEP.

Description :cette phase regroupe :

  • les travaux de développement (spécifications détaillées, programmation, tests divers, validation de maquette) ;

  • la validation des livrables ;

  • les opérations relatives au déploiement du futur système (installation, intégration sur site pilote, site(s) de production, etc.).

Au sein de cette phase le GTEP statuera sur l\'affermissement des éventuelles tranches conditionnelles.

EXPLOITATION.

Début : date de début de l\'exploitation de l\'application.

Fin : date de retrait de l\'application ou migration vers une nouvelle évolution technique ou fonctionnelle majeure de l\'application.

Description : cette phase regroupe les dépenses afférentes au fonctionnement normal du système (maintien en condition opérationnelle et tierce maintenance applicative).

RETRAIT de SERVICE.

Début : date de début de retrait.

Fin : date de fin de retrait.

Description : le processus de retrait de service d\'une application doit être décrit dès qu\'une refonte est envisagée. La date de retrait doit être renseignée.