direction des affaires financières : sous-direction de la prospective et de l'analyse des coûts

INSTRUCTION N° 15908/DEF/SGA/DAF relative au suivi financier des investissements du ministère de la défense.

Du 16 mai 2017
NOR D E F S 1 7 5 1 0 2 3 J

Référence(s) :

Instruction générale n° 31475 du 5 août 1998 (n.i. BO).

Autre N° 22912/DEF/SGA/DAJ/D2P du 26 mars 2010 relative à la gouvernance des investissements du ministère de la défense. Instruction générale N° 125/DEF/EMA/PLANS/COCA - N° 1516/DEF/DGA/DP/SDM du 26 mars 2010 relative au déroulement et la conduite des opérations d'armement - tome II (documents types).

Charte Financière n° 1001719/DEF/SGA/DAF/SPB/SPB1 du 21 juillet 2010 (n.i. BO).

Pièce(s) jointe(s) : Six annexes.

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

Référence de publication : BOC n°40 du 28/9/2017

1. Objet.

Cette instruction constitue le fascicule thématique relatif au « suivi financier des investissements » de la Charte financière du ministère de la défense.

Le suivi financier contribue à la maîtrise du budget confié au ministère de la défense. Il s'étend aux domaines budgétaire, comptable et analytique. Il couvre le coût complet, hors titre 2 ⁽¹⁾, des « biens » du ministère avec le détail de celui-ci, établissant ainsi un lien opposable entre le financier et le physique associé.

Le suivi financier est instrumenté, au ministère de la défense, dans un système d'informations dédié, le module « Project System » (PS), intégré à l'application CHORUS, dont, toutefois, il ne met en œuvre que les fonctionnalités financières.

Le module PS utilise un support dédié appelé « projet » pour suivre les dépenses des investissements tout au long de leur vie, quelles que soient leurs dates d'apparition (ou leurs stades de rattachement) dans le cycle de vie du « bien ».

PS offre ainsi la souplesse de collecter les dépenses de chaque investissement concerné, avec un lien univoque entre l'investissement et la dépense, par type de matériel, au niveau de granularité souhaité, sur une longue période, selon un procédé constant, indépendant du temps et des évolutions des autres référentiels.

L'objet de ce fascicule est d'expliquer :

les principes généraux et structurants du suivi financier des investissements ;
le suivi financier et les règles d'application du module Project System de CHORUS au sein du ministère de la défense ;
les modalités de gestion et de suivi des projets de PS et des éléments d'organigramme technique de projet (éOTP) ;
les rôles des différents acteurs et leurs responsabilités ;
les règles de contrôle ;
l'exploitation des données du module.

2. Domaine d'application.

Les directives de ce document ont vocation à s'appliquer aux investissements du ministère de la défense ainsi qu'à « tout élément spécifique nécessitant un suivi financier individualisé » [par exemple, les projets en partenariat public privé (PPP), d'externalisation, etc.].

Les investissements du ministère de la défense ont donc vocation à être inscrits dans le référentiel des projets du ministère mais d'autres projets spécifiques peuvent aussi faire partie de ce référentiel.

1. PRINCIPES GÉNÉRAUX ET STRUCTURANTS DU SUIVI FINANCIER.

1.1. Objectifs du suivi financier des projets.

Le suivi financier des projets contribue aux objectifs suivants :

participer à l'établissement d'un référentiel des projets, partagé et reconnu, permettant de connaître la liste des « biens » possédés au sein du ministère de la défense ;
fournir une visibilité financière consolidée au niveau ministériel, actualisée et partagée de chaque projet ⁽²⁾sur toute sa durée de vie ;
collecter les dépenses constituant les immobilisations en cours (IEC) pour l'enregistrement à l'actif du bilan de l'État des biens résultant des projets d'investissement ;
concourir au développement d'une comptabilité analytique permettant une connaissance plus complète et détaillée des coûts ;
construire l'évaluation du coût global (CG) de chaque projet du ministère et permettre de suivre la soutenabilité financière du projet par rapport aux estimations initiales.

Le suivi financier des projets du ministère de la défense constitue un outil de la politique d'investissement du ministère et du suivi de la soutenabilité des projets par la prise en considération du long terme et de tous les éléments transverses relatifs à un investissement.

Le suivi financier sert à fournir une information financière détaillée ; cette information est d'un détail supérieur à celle délivrée par la consommation des crédits du référentiel budgétaire de programmation.

Il permet d'établir un lien univoque entre le physique et les montants associés.

1.2. Le module « project system ».

Au ministère de la défense, le suivi financier des projets est instrumenté via le module Project System (PS) de CHORUS. Le module « PS » constitue l'« axe projet » de CHORUS.

Le ministère n'utilise que les fonctionnalités de suivi financier de ce module.

Le principe du module PS est de suivre les éléments concernés via un support appelé « projet ». Pour le suivi financier des investissements du MinDef, sur toute leur vie, le terme « projet » est conservé mais il correspond seulement au support informatif que le module PS (« Project » system) de CHORUS emploie pour ces investissements, sans limitations donc aux seuls stades amont comme par exemple les investissements « en projet ».

Les principales possibilités de ce module sont :

le suivi financier du projet grâce à l'imputation de toutes ses dépenses hors T2 (et ressources éventuelles) ;
le suivi financier sur une structure arborescente et selon une codification spécifique ;
l'enregistrement d'une prévision financière, appelée « pré-budgétisation ».

Le suivi financier des projets dans une application unique, CHORUS, permet en outre d'être en interface direct avec les autres modules de ce progiciel de gestion intégré ⁽³⁾ (outils de gestion budgétaire, comptable, processus d'engagement et de dépenses, etc.).

1.3. De l'importance de définir des structures de projet.

Le suivi financier des projets s'appuie sur la mise en place d'une arborescence ou « structure » permettant de collecter les coûts de manière homogène.

L'objectif de la structuration d'un projet est d'identifier la maille informative minimale suffisante pour fournir la visibilité recherchée sur les coûts ⁽⁴⁾ des investissements.

La déclinaison structurée d'un projet sur la totalité de son cycle de vie, depuis son expression de besoin jusqu'à la fin de sa vie, permet de détailler le coût global d'un investissement.

Il n'y a pas association systématique entre un projet et un niveau de l'organisation budgétaire et comptable ou entre un projet et un niveau de programmation budgétaire.

1.4. Le recueil des coûts en projet.

Le suivi d'un investissement dans un « projet » permet d'enregistrer et de suivre l'ensemble de ses coûts (par exemple, suivi des coûts imputés sur un « projet à effet majeur » (PEM), avec les sous-projets qui lui sont associés : projets d'environnement, exploitation, entretien programmé des matériels (EPM), système d'information, infrastructure, etc.).

La collecte organisée des coûts par élément du projet permet de consolider les dépenses au profit de la comptabilité analytique.

1.5. Comparaison avec les prévisions initiales d'investissement.

Chaque projet peut faire l'objet d'une prévision de dépenses et de recettes pour engagement et paiement. Le module PS « Project system » permet d'enregistrer, via sa fonctionnalité de « pré-budgétisation », les coûts prévisionnels de ces projets afin de pouvoir les comparer aux montants réalisés. Une comparaison « prévu/réalisé » identifie les écarts éventuels. Ceux-ci ont vocation à être expliqués.

1.6. Utilisation des données de CHORUS et de project system au sein des instances de gouvernance.

Les données financières enregistrées dans CHORUS ont vocation à éclairer l'examen des investissements dans les instances de gouvernance des investissements [CMI, CSIC, CSIAG ⁽⁵⁾, CEP, CMDE, notamment], sans se substituer au référentiel de programmation.

2. SUIVI FINANCIER ET RÈGLE D'APPLICATION DU MODULE project system.

Au ministère de la défense, le module Project System est utilisé pour le suivi financier de « tout élément spécifique nécessitant un suivi financier individualisé », principalement pour le suivi financier des « biens » du ministère.

En particulier, les éléments suivants sont soumis à ce suivi :

les équipements ;
les infrastructures ;
les systèmes d'information ;
les études amont.

Par ailleurs, le module Project System peut permettre de suivre le coût d'opérations particulières, au-delà des référentiels existants [tels le suivi de projets complexes, emblématiques, les projets en partenariat public privé (PPP), les externalisations, etc.].

2.1. Structuration d'un projet en organigramme technique de projet.

2.1.1. Cas général de structuration de projet.

Chaque « projet PS » doit être décrit par un nom et repéré par un identifiant unique.

Il est représenté par une arborescence hiérarchisée : un « organigramme technique de projet » (OTP).

Celui-ci est composé d'éléments distincts : les « éléments d'organigrammes techniques de projet » (éOTP).

Les éOTP de bout de branches constituent les « collecteurs de charges » ⁽⁶⁾ élémentaires (et éventuellement de produits) et sont dénommés « éOTP imputables ».

Le terme « éOTP » est utilisé autant pour les éléments imputables que pour un groupe d'éOTP groupés en branche ou sous-branche.

Les branches sont spécialisées par programme de la loi organique relative aux lois de finances (LOLF) (un seul programme par branche). Plusieurs branches financées par le même programme LOLF peuvent toutefois coexister dans le même projet.

Chaque éOTP porte un identifiant propre et unique.

Chaque « projet PS » est représentatif d'un « élément nécessitant un suivi individualisé ». Il représente, le plus souvent, un « investissement ⁽⁷⁾ » du ministère et un seul ⁽⁸⁾. Ce « sujet » ou « bien » peut être matériel ou non (e.g. études). Il a vocation à collecter l'intégralité des coûts (i.e. dépenses et recettes) relatifs au sujet du projet considéré. Autrement dit, il n'y a qu'un projet PS par « sujet » de projet identifié.

Il n'y pas nécessairement de bijection entre projet et activité budgétaire.

2.1.2. Structures type de projets.

Des structures type d'arborescence sont définies afin d'harmoniser les projets et de faciliter leur création. Elles figurent en annexe. Elles doivent être utilisées pour les cas concernés. Les niveaux avals, uniquement, peuvent être adaptés aux besoins spécifiques des utilisateurs.

Ces modèles couvrent les projets d'équipements militaires acquis dans le cadre des opérations d'armement (définies par l'IM 1516), les opérations de maintien en condition opérationnelle de ces équipements ainsi que les opérations d'infrastructure, les systèmes d'information opérationnelle et de communication (SIOC), les autres opérations d'armement, les systèmes majeurs d'information d'administration et de gestion (SIAG) et les études amont. Ces structures prédéfinies simplifient la lisibilité des projets par effet d'harmonisation.

Tous les projets sous PS doivent se conformer à ces structures qui peuvent se combiner lorsque, par exemple, un projet comporte un équipement militaire, de l'infrastructure et du maintien en condition opérationnelle.

2.1.3. Cas particulier de structuration de projets.

Les éOTP ne sont pas mono service exécutants. Toutefois, les éOTP sont spécialisés par le paramètre CCR (Centre de Coûts Responsable). Le code positionné en « Centre de coûts responsable » de l'éOTP est, en général, un code de service gestionnaire de bien (SGB).

Il est techniquement possible d'imputer des dépenses relevant de plusieurs SGB sur un même éOTP ; toutefois, l'accord préalable du SGB indiqué en paramètre CCR est requis.

Il est possible d'outiller l'axe projet pour le suivi détaillé, interne aux services, de certains projets spécifiques. Ce suivi est établi en compatibilité avec les règles de structuration dans le cadre d'un dialogue avec l'administrateur ministériel des projets.

Par dérogation au point 3.1.2. « Structures type de projets », des projets peuvent être créés pour répondre à des besoins particuliers tels le suivi financier des opérations du fond de restructuration des entreprises de défense (FRED).

Dans ces cas, limités, des structures ad hoc sont réalisées avec l'aide de l'administrateur ministériel des projets qui les valide ou les refuse en dernier ressort.

2.1.4. Éligibilité d'un « bien » à constituer un nouveau projet project system.

Afin de déterminer s'il faut, pour un nouveau bien, créer un « projet PS » à part entière ou le rattacher à un projet existant, il convient de statuer s'il répond à l'un ou l'autre des critères suivants :

ce bien aurait-il été acquis en l'absence du bien principal (à défaut, c'est alors le cas d'un « bien » annexe ou complémentaire au principal ?) ;
ce bien nouveau peut-il être affecté, lors de son lancement, à plusieurs biens principaux ? (à défaut, cela signifie qu'il n'a pas d'affectations multiples mais une affectation unique, initiale, à « un » bien principal a priori déjà suivi sous PS).

S'il ne satisfait pas l'un ou l'autre de ces critères, alors le nouveau « bien » est incorporé dans le projet du « bien » principal. Dans les autres cas, le « bien » nouveau justifie la création d'un nouveau projet PS.

Les biens « incorporables » (donc non reconnus comme justifiant d'un projet PS en propre) constituent une branche, en général dédiée, du projet existant.

Lorsque l'investissement n'est pas spécifique à un équipement principal et qu'il peut devenir commun à plusieurs biens, il peut faire l'objet d'un projet spécifique.

2.2. Les éléments d'organigramme technique de projet.

2.2.1. Règles de collecte des dépenses et recettes sur les éléments d'organigramme technique de projet.

Les éOTP collectent (et les projets consolident) les coûts hors titre 2 directement rapportés et imputés sans calcul au bien principal ⁽⁹⁾ de tous les objets directement affectables au bien principal ⁽¹⁰⁾.

Les coûts de titre 2 ne sont pas imputables, à ce jour, sur l'axe projet.

Dès l'engagement, toutes les dépenses directement imputables à un projet doivent l'être dès lors que le contrat permet de distinguer, au niveau de détail le plus fin de l'engagement juridique (en fait la ligne de gestion), les montants engagés exclusivement pour un investissement donné.

Dans le cas où un engagement concerne plusieurs investissements, sans distinction possible de ceux-ci dans la ligne de gestion (LG) lors de la saisie, mais que la constatation du service fait (CSF) permet de constater l'exécution du contrat répartie par investissement, il convient, dans le respect des dispositions imposées par la réglementation des marchés, de traduire cette ventilation par investissement dans les projets d'appartenance de ces investissements

Le processus préconisé est le suivant :

L'engagement juridique et la ligne de gestion concernée doivent être modifiés en répartissant la ligne de gestion initiale en plusieurs lignes de gestion afin de permettre l'imputation des coûts sur les éOTP, donc les investissements concernés. Ces lignes de gestion doivent être conformes et cohérentes avec la nature de la dépense, les FIEC ⁽¹¹⁾ de déversements concernées et les différents axes de financement.

Les informations DF, CF et DA doivent être renseignées obligatoirement pour les éOTP typés IA ⁽¹²⁾ ; toutes ces informations doivent être cohérentes avec les axes de financement de la dépense concernée et la (ou les) FIEC de déversement. Toutefois, les éOTP IA ont vocation à être mis en extinction. Ils n'ont pas vocation à être modifiés en TFG (Travaux de Fin de Gestion).

Les règles ⁽¹³⁾ de ré-imputation sont prescrites par la DAF de manière à être mises en œuvre par les RDP et GDP (Responsable et Demandeur de la Demande de Paiement) et vérifiées dans le cadre du contrôle interne financier par les RUO.

2.2.2. Principes d'éligibilité d'une dépense à son imputation dans un projet project system.

Le fascicule sur le coût global, annexé à l'instruction générale n° 22912/DEF/SGA/DAJ/D2P du 26 mars 2010 relative à la gouvernance des investissements du ministère de la défense, stipule que le coût global prend en compte tous les « coûts relatifs à un investissement ».

L'un des critères d'éligibilité d'un coût à son inscription dans le coût global est que ce coût « n'aurait pas été supporté en l'absence de l'investissement ». Les coûts répondant à ce critère doivent être imputés, puis collectés, dans le projet de l'investissement concerné.

2.2.3. Codification des projets et éléments d'organigramme technique de projet.

Chaque projet ou éOTP est identifié individuellement par un code alphanumérique unique.

La codification a pour but d'assurer la cohérence d'ensemble du référentiel des projets et éOTP. Tous les codes des projets et éOTP ont vocation à répondre à une logique et à une cohérence sémantique d'ensemble dont les principes sont décrits en annexe. L'objectif est d'en simplifier et d'en harmoniser la lecture.

Le nombre de caractères disponible sous PS (Project System) pour installer le code est limité. Compte tenu de cette limitation, l'administrateur peut être amené à imposer une partie du libellé de l'éOTP (exemple : commencer le libellé par le site géographique (ex : BA113) pour un éOTP d'infrastructure).

Dans le cas des éOTP IA, le service chargé du niveau imputable peut déroger si nécessaire à la règle imposée et s'adapter pour permettre de gérer efficacement les différents contrôles internes, sans pour autant intervenir sur la part du code du niveau au-dessus/en amont de son niveau d'intervention.

Ce code d'éOTP de l'ensemble du projet ou d'une partie du projet est utilisé chaque fois qu'il s'agit d'identifier précisément des investissements ou de suivre les informations financières qui s'y rapportent.

2.2.4. Traitement des révisions de prix.

Les révisions de prix (RP/HE) ⁽¹⁴⁾ sont ici définies comme la différence entre le montant payé par application de la formule contractuelle de révision de prix du marché et le montant initial de l'engagement contractuel. Les principes de suivi des RP/HE s'appuient sur des schémas standards de CHORUS, déjà validés.

Les révisions de prix, et donc leurs montants, doivent être identifiables en tant que telles, sans confusion, et rattachées au bien-sujet de dépense auquel elles se rapportent (i.e. collectées dans le projet PS du bien), comme détaillé en appendice I.D.

2.2.5. Traitement des intérêts moratoires.

Les intérêts moratoires (IM) sont considérés comme faisant partie du coût du projet. Les principes de suivi des IM s'appuient sur des schémas standards de CHORUS, déjà validés (cf. appendice I.E.).

Les IM, et donc leurs montants, doivent être identifiables en tant que tels, sans confusion, et rattachés au bien-sujet de dépense auquel ils se rapportent (i.e. collectés dans le projet PS du bien).

2.2.6. Traitement des pénalités.

Les pénalités, imposées par l'acheteur « État » à son fournisseur, doivent être traitées en tant que produits « recettes ». Il convient de ne pas compenser créance et pénalité au niveau de la demande de paiement. Concernant les dépenses d'immobilisations, les pénalités sont sans incidence sur la valorisation de l'encours et a fortiori sur la FIES ⁽¹⁵⁾. Les principes de suivi des pénalités s'appuient sur des schémas standards de CHORUS, déjà validés.

Les pénalités, et donc leurs montants, doivent être identifiables en tant que telles, sans confusion, et rattachées au bien-sujet de dépense auquel elles se rapportent (i.e. collectées dans le projet PS du bien). Pour cela, le processus décrit en appendice I.F. est préconisé.

2.2.7. Coûts historiques.

Les coûts antérieurs à la mise en service de CHORUS (01/01/2010) ne sont pas présents dans CHORUS. Certains coûts antérieurs ont toutefois un intérêt pour la connaissance du coût global des biens auxquels ils se rapportent. Ces coûts sont appelés « coûts historiques ». Ils sont destinés à être insérés par la DAF dans PS dans des éOTP dédiés dits « éOTP historiques » portant un code spécifique.

2.3. Pré-budgétisation des coûts (et ressources).

2.3.1. Fonctionnalités de pré-budgétisation.

La pré-budgétisation est une fonctionnalité du module PS permettant :

d'enregistrer des montants prévisionnels, initiaux et révisés (comme l'estimation initiale du coût global de l'investissement ayant été considérée lors de la décision de lancement), tant en besoins qu'en ressources, indépendamment du niveau de couverture réel des crédits ;
de disposer à la fois (i.e. sur le même support : CHORUS), et à fins éventuelles de comparaison :
- des montants réels « constatés », par la collecte des coûts dans les éOTP, et ;
- des montants prévisionnels ⁽¹⁶⁾ de chaque partie pré-budgétée du projet (projet complet, branche ou sous-branche) ;
de disposer d'échéanciers financiers prévisionnels à jour dans le cadre des versions révisées.

La pré-budgétisation est une prévision financière. Elle retranscrit aussi bien un coût prévisionnel (comme la prévision de devis à terminaison) qu'une ressource prévisionnelle.

La fonctionnalité de pré-budgétisation a vocation à fournir des échéanciers prévisionnels de besoins futurs (AE ou CP) ou de ressources futures (AE ou CP) allouables aux projets ou encore de donner le rythme des engagements et des paiements prévisibles. La disposition d'échéanciers à jour s'inscrit dans la planification globale des besoins d'AE (anticipation des besoins financiers), de CP (gestion de trésorerie) et dans la vérification des engagements et des paiements.

La maille physique de saisie des pré-budgets est définie en fonction du type de projet, de son stade d'avancement et du niveau d'exigences d'informations, ainsi que du niveau de pilotage attendu par le ministère.

Le « champ d'appréciation » prioritaire du pré-budget est le coût global ⁽¹⁷⁾. L'objectif est de connaître au plus tôt le montant total auquel sont engagées les finances publiques à long terme du fait du lancement du projet.

Les pré-budgets permettent d'identifier des écarts entre le « réalisé » et ce qui a été prévu (le « prévisionnel » ou « prévu » ; ils ne permettent pas d'expliquer ces écarts, ni de les corriger. L'explication des écarts réside en général dans des évolutions de contenu, de planning ou d'indices prévisionnels, voire dans l'impact d'un effet « monnaie ».

La pré-budgétisation diffère de la programmation notamment par :

la maille physique (le « bien » instrumenté par le projet PS pour la pré-budgétisation versus l'activité budgétaire pour la programmation) ;
l'horizon temporel (la durée de vie, voire le stade, versus une période limitée dans la programmation) ;
la nature (construction prévisionnelle fondée sur une estimation versus une allocation de ressources immédiates et réelles par loi de finances initiale).

Les chiffres prévisionnels des pré-budgets sont les chiffres les plus récents apparaissant dans des documents de référence reconnus et validés. Ce sont les chiffres des dossiers de lancement d'investissement et de franchissement de jalon de stade pour les deux premières versions et, a minima, les chiffres de sortie de VAR pour la troisième version. En conséquence, ils sont validés et incorporés dans CHORUS lors de l'approbation de ces documents source.

La première saisie des pré-budgets, pour l'ensemble de la vie de l'équipement, doit intervenir, et dans la mesure du possible, au plus tard au DOC ⁽¹⁸⁾ voire au dossier de lancement de la réalisation (DLR). (Les éventuelles « fourchettes » de valeur peuvent être mises en « information textuelle »).

2.3.2. Champ d'application de la pré-budgétisation.

Les projets d'investissement ministériels sont généralement imputables sur plusieurs programmes LOLF et échappent à la compétence exclusive d'un seul RPROG. Leur suivi nécessite de pouvoir consolider leurs montants prévisionnels au niveau ministériel, avec les chiffres des divers RPROG contributeurs.

De même, leurs risques financiers doivent s'apprécier à un niveau ministériel.

Les pré-budgets s'appliqueront préférentiellement aux projets d'investissement répondant aux critères ci-dessous :

I. Au titre de la consolidation des coûts :

a) aux grands programmes d'armement satisfaisant l'une des conditions suivantes :

un financement par plusieurs programmes LOLF (programmes « multi-imputés ») ;
la mise en place d'une seule tranche fonctionnelle (TF) pour le programme, lequel étant toutefois constitué de plusieurs sous-ensembles ;

b) aux projets en PPP (partenariat public-privé) ou d'externalisation qui sont éligibles à un examen :

soit en comité ministériel d'investissement (CMI) ;
soit en comité ministériel des soutiens (CMS) ;

c) aux opérations de MCO (non rattachées à un PEM suivi sous PS) satisfaisant l'un des critères suivants :

soit éligibles à un examen en CMI ;
soit consistant en opérations d'ampleur regroupant plusieurs marchés (par exemple l'arrêt technique majeur d'un bateau).

II. Au titre de la maitrise des risques :

a) aux programmes d'infrastructure (hors PEM suivis dans PS) satisfaisant l'une des conditions suivantes :

soit éligibles à un examen en CMI ;
soit intervenant sur plusieurs sites géographiques ;
soit constitués de sous-ensembles s'exécutant à des rythmes différents.

b) aux projets de système d'information éligibles à un passage en CMI ;

c) à tout projet que la commission exécutive permanente (CEP) aura désigné en raison de l'importance des risques associés.

Pour les projets utilisant la fonction pré-budget, les informations à saisir de façon obligatoire sont : la version initiale de décision d'investissement (VIDI), la version de cible glissante financière (VCGF) et la version dynamique d'expression de besoins (VDEB), qui sont définies en annexe IV.

2.3.3. Déploiement de la pré-budgétisation.

Le déploiement de la fonctionnalité « pré-budget » fera l'objet de protocoles, distincts de la présente instruction, entre la DAF et chaque responsable de programme LOLF (ou leurs délégués).

2.4. Aspects comptables.

2.4.1. Principes d'imputation.

En qualité de « collecteurs de coûts », les éOTPs sont soumis aux règles conventionnelles définies par la LOLF.

2.4.2. Principes de comptabilité générale.

Pour la comptabilité des immobilisations, la gestion comptable du ministère de la défense mise en place dans CHORUS se traduit notamment par la mise en œuvre d'une comptabilité auxiliaire des immobilisations en cours (IEC) et en service (IES).

Les immobilisations sont valorisées directement ou indirectement selon les types d'immobilisations concernées :

la valorisation directe concerne les « immobilisations simples ». Dans ce cas, les éOTP sont des « collecteurs de coûts de type IE ⁽¹⁹⁾ », qualifiés d'« immobilisés », statistiques par défaut. Ils ne nécessitent pas d'opérations de déversements sur des fiches d'immobilisations en cours (FIEC) d'acquisition (et celles-ci ne sont d'ailleurs pas possibles) ;
la valorisation indirecte concerne les « immobilisations complexes ». Dans ce cas, les éOTP sont des « collecteurs de coûts de type IA ⁽²⁰⁾», qualifiés d'« immobilisables », non statistiques, pour lesquels un déversement sur des fiches d'immobilisations en cours (FIEC) est requis (éOTP non statistiques). Les clés de déversement afférentes à chaque éOTP (dites « règles d'imputation ») permettent de déverser les montants collectés vers la ou les fiches d'immobilisations en cours (FIEC) pour la valorisation des immobilisations corporelles et incorporelles. Les éOTP IA ont vocation à être supprimés progressivement.

2.4.3. Extinction progressive des éléments d'organigramme technique de projet immobilisables.

Les éOTP immobilisables sont globalement porteurs de davantage de contraintes que de bénéfices :

ils imposent un lien entre le référentiel des projets et les référentiels budgétaro-comptables ;
ils imposent de ce fait des circuits d'information plus complexes que les autres éOTP ;
ils génèrent des contraintes chronophages pour les acteurs comptables des directions et services, de la DAF et des comptables publics.

Ces éOTP étant encore toutefois utilisés assez largement, une trajectoire de mise en extinction progressive sera définie par la DAF en concertation avec les services qui les utilisent.

3. GESTION ET SUIVI DES PROJETS ET éléments d'organigramme technique de projet.

3.1. Organisation du suivi et de la gestion des projets et éléments d'organigramme technique de projet.

L'organisation du suivi et de la gestion des projets et des éOTP vise à :

s'assurer de l'utilisation des projets, des éOTP et de PS (Project System) conformément à cette instruction ;
répartir de façon précise les responsabilités et les rôles entre les différents acteurs ;
centraliser et entretenir une connaissance à jour des projets et de leurs éOTP existants au ministère (liste, structure des projets, respect des opérations de suivi, etc.) ;
entretenir et diffuser la connaissance sur la gestion et le suivi en projets et éOTP du ministère (formation) ;
entretenir un référentiel des projets sous PS dans CHORUS.

3.2. Consultation et modification des informations de l'axe projet.

Les services devant consulter, renseigner ou modifier des informations ou des éléments (structures) doivent posséder des habilitations spécifiques, en sus des accès CHORUS habituels. Les habilitations portent sur les codes de centre de coût responsable (CCR) et de centre de profit des éOTP.

Un service qui est habilité à la fois sur les codes d'un centre de profit et d'un centre de coût responsable d'un éOTP peut procéder à des modifications de celui-ci.

Un service qui n'est habilité que sur un centre de coût responsable (CCR) ou sur un centre de profit d'un éOTP ne peut que consulter les informations de celui-ci.

Le module PS ne permet toutefois pas d'enregistrer des informations classifiées.

3.3. Processus général de création ou de modification d'un projet ou d'éléments d'organigramme technique de projet.

Dans tous les cas, le demandeur conserve la responsabilité de vérifier ou faire vérifier la structure créée et les paramètres des éOTPs de sa branche.

Certaines opérations (e.g. vérification, lancement, etc.) peuvent être déléguées à la direction de programme, ou équivalents. Cette délégation peut être fournie par service, par projet ou branche ou autres ; elle peut être limitée dans le temps ou permanente.

Le processus de création d'un projet ou éOTP nouveau ou de modification d'un projet ou éOTP existant, se déroule selon le principe décrit en appendice I.G.

3.4. Cas spécifiques.

3.4.1. Cas particulier de demandes spécifiques de la part des autorités de gouvernance.

Dans le cas particulier où des autorités de gouvernance émettent des demandes spécifiques de suivi ou d'information de gestion, la direction des affaires financières traite celles-ci et en détermine la traduction technique dans PS.

Elle renvoie à chaque acteur du processus la part qu'il lui revient de mettre en œuvre dans PS.

3.4.2. Cas des modifications fréquentes des éléments d'organigramme technique de projet imputables.

Le responsable de programme (RPROG) ⁽²¹⁾ est responsable de la tenue (création, modification, suppression éventuelle) des éOTP du niveau imputable, dans le respect de la structure convenue. Leur modification est fonction des besoins rencontrés dans le cadre de l'exécution des engagements juridiques à imputer sur le projet. Elle ne requiert pas de validation spécifique de l'administrateur, mais une simple information.

Le responsable de la tenue de l'éOTP est l'organisme indiqué en « tête de branche » des structure PS ; les branches des projets PS sont généralement spécialisées par programme LOLF. Son délégataire est l'entité dont le code est positionné dans le paramètre PS « Centre de coûts responsable » (CCR) de l'éOTP, en général, un code de service gestionnaire de bien (SGB).

Les éOTP modifiés doivent se trouver dans la branche du « tête de la branche » (e.g. RPROG) dont dépend le modificateur. Dans le cas où les éOTP créés ne sont pas situés dans la branche de sa « tête de la branche », le modificateur doit requérir l'accord de la « tête de la branche » de la branche d'accueil pour y implanter sa branche. Dans les deux cas, les créations sont effectuées dans le respect des structures convenues.

Pour les projets transverses à plusieurs programmes LOLF et afin de donner l'accès en modification au gestionnaire de projet souhaitant intervenir, la modification nécessite toutefois une intervention de la direction des affaires financières. En ce cas et suite à demande, elle paramètre temporairement le code du centre de profit intervenant sur le projet concerné (sur la « définition de projet »).

3.4.3. Cas dérogatoire de création de branche spécifique à un responsable de la comptabilité auxiliaire des immobilisations ministériel ou à un service gestionnaire de biens.

Il peut être créé une branche spécifique à un RCAIM ou à un SGB, dit « incident », dans la structure du projet dans le cas où le service gestionnaire de biens (SGB) ne dépend pas du responsable de la branche « receveuse ».

Ce cas est dérogatoire à la règle générale. Il se déroule selon le processus décrit en appendice I.H.

3.4.4. Contraintes particulières relatives aux clôtures d'éléments d'organigramme technique de projet ou de projet.

Au terme de chaque étape temporelle (stade, phase, retrait de service), la direction de programme ou équivalent, initialise puis, après validation par la direction des affaires financières, procède à la clôture de l'éOTP concerné.

Cette clôture est réversible. La clôture, et l'annulation de clôture, du projet est uniquement effectuée par la direction des affaires financières. Elle se déroule selon le processus décrit en appendice I.I.

3.4.5. Processus particulier pour l'utilisation des « codes de regroupement ».

La gestion et l'emploi des codes de regroupement relèvent exclusivement de la direction des affaires financières.

Toute demande de regroupement de projets sera adressée à la direction des affaires financières qui examinera l'opportunité de regrouper les projets et le cas échéant réalisera l'opération grâce à un « code de regroupement ».

4. RÔLES DES DIFFÉRENTS ACTEURS ET RESPONSABILITÉS.

4.1. La direction des affaires financières.

La direction des affaires financières exerce la fonction d'administrateur ministériel des projets.

A ce titre, elle a les rôles suivants :

garante de l'usage de la notion de projet et d'éOTP et autres concepts associés, en conformité avec les définitions de référence et la doctrine ;
point d'entrée du ministère de la défense pour tous les acteurs ayant à recourir ou à s'informer sur les projets et éOTP (principes, création, suivi, clôture, etc.) ;
responsable du référentiel des projets ;
conseil et information des responsables de programme (RPROG), des directions de programmes ou équivalents, des acteurs de la chaîne financière, des gestionnaires de projet et d'éOTP, des responsables de la comptabilisation auxiliaire des immobilisations ministériels (RCAIM) et des services exécutants (SE).

A ce titre, elle exécute les tâches suivantes :

elle examine et valide les propositions de structuration des projets et leur déclinaison en éOTP ;
elle valide les créations et modifications des projets et éOTP conformément aux modèles de projet et elle valide les clôtures d'éOTP ;
elle analyse également les demandes de dérogations à l'emploi de la structure agrégée/consolidée des opérations d'armement et émet un avis sur ces demandes ;
elle supervise la correcte tenue des projets et de leurs éOTP existants ;
elle assure la cohérence des structures des différents projets entre les grandes entités du ministère ;
elle supervise la saisie des pré-budgets ;
de plus la direction des affaires financières a la charge de diffuser, promouvoir et améliorer la doctrine (vulgarisation, formation, documentation, etc.).

Pour cela, la direction des affaires financières dispose de moyens d'action et d'intervention, et notamment des suivants :

elle détermine la codification des projets et éOTPs ;
elle définit et valide les structures type de projets ;
elle renseigne les « statuts », sous PS, des projets (en particulier durant les processus de création, modification, fermeture) ;
elle intervient sur le contrôle des projets et éOTP (structure, paramétrage, règles, etc.) ;
elle dispose de la possibilité de bloquer la création ou l'usage de projet et d'éOTP si ceux-ci n'en respectent pas les principes (avec information préalable du responsable de programme ou de son représentant).

4.2. La chaîne financière (responsable de programme, responsable du budget opérationnel de programme, responsable d'unité opérationnel) et les directeurs de programmes.

4.2.1. Le responsable de programme.

Le RPROG est le responsable du « devis » de la branche. Il assure la supervision du budget du programme LOLF relatif à cette branche du projet. Il assure le suivi des coûts consolidés sur ce périmètre.

Le RPROG, ou délégué, correspond dans l'éOTP au paramètre « Centre de Profit ».

Le responsable de programme (RPROG) peut déléguer tout ou partie de ces tâches aux RBOP ou RUO.

Selon son organisation, le RPROG peut déléguer des tâches à la direction de programme, ou équivalent ⁽²²⁾, au sens PS, de chaque projet (en fait, de chaque branche du projet).

Pour les éléments de PS le concernant, le responsable de programme (RPROG) ou délégué :

assume la responsabilité des projets et éOTP et supervise la correcte tenue de ceux-ci ;
assume la responsabilité globale de la gestion courante des éOTP (opérations de création, modification, clôture, imputations budgétaires, imputations/référencement des dépenses aux éOTP) dont il est le « centre de profit » quel que soit le service exécutant imputant sur son périmètre ;
assure la validité des montants inscrits en pré-budgets, s'il y a lieu (pour les chiffres de son ressort).

Pour cela, le RPROG, ou délégué :

propose à la direction des affaires financières les structures à créer pour les nouveaux projets, sur le fondement des structures types ;
détermine l'éOTP à référencer dans chaque ligne de gestion (LG) et s'assure de la transmission de ces consignes d'imputation (de LG aux éOTP) vers les services exécutants ;
demande de modifier le statut des éOTP à la direction des affaires financières ;
vérifie si les projets sont actifs ou inactifs et éventuellement propose à la DAF la clôture des projets inactifs ;
indique les données de pré-budgets à saisir dans PS et les éOTP correspondants, s'il y a lieu (pour les chiffres de son ressort).

Le responsable de la tenue de l'éOTP (paramétrage, création, modification, suppression éventuelle, etc.) est l'entité indiqué en « tête de branche » des structure PS ; il est identifié, ou son représentant, par l'organisme dont le code est positionné dans le paramètre PS « Centre de coûts responsable » (CCR) de l'éOTP, en général un SGB (service gestionnaire de bien). La « bonne tenue » des éOTP concerne le paramétrage, tenue à jour incluse, des éOTP ainsi que les opérations associées (déversements), sans la possibilité de création d'éOTP -sauf déjà validée- ou de modification des codes.

Le gestionnaire de projet est considéré comme un acteur de la direction de programme ou équivalent, sous contrôle du RPROG, qui :

propose les créations, modifications, fermetures des projets et des éOTP de son périmètre d'habilitation dans les structures validées ;
vérifie les projets et éOTP (structure, paramètres, règles d'imputation et de déversement, etc.) créés par l'administrateur (en général à la demande du gestionnaire de projet) ;
saisit les pré-budgets, s'il y a lieu ;
demande les changements de statut des éOTP ;
gère et contrôle les imputations de lignes de gestion sur les éOTP.

4.2.2. Les Directeurs de Programme et les responsables de budget opérationnel de programme et d'unité opérationnel.

Le Directeur de Programme [ou son équivalent ⁽²³⁾] est chargé de la conduite du projet, durant toute la vie de celui-ci, et a la responsabilité permanente :

d'initialiser les modifications des paramètres relatifs au projet ;
d'initialiser puis d'appliquer, après validation par l'administrateur des projets (i.e. la DAF), les modifications du projet ou de sa structure et les modifications d'éOTP ;
de conserver les projets et éOTP en conformité avec les structures agréées.

Le centre financier, BOP ou UO, s'assure que les services exécutants (SE) disposent des consignes d'imputation des lignes de gestion (LG) aux éOTP. En particulier lors des demandes d'engagement juridique et pour chaque ligne de gestion, il s'assure de la cohérence de ces éléments avec la nature de la dépense (nature du poste d'EJ, groupe de marchandise, type éOTP, le cas échéant référence de la FIEC, etc.).

4.3. Le service exécutant.

Le service exécutant est responsable de la correcte application des consignes imputation (des lignes de gestion aux éOTP). Cette imputation se fait selon des modalités fixées à cet effet.

Pour cela, lors de la saisie d'engagement juridique [d'ET ⁽²⁴⁾ ou OA ⁽²⁵⁾], le SE renseigne les éOTP ad hoc sur le fondement des consignes d'imputation, des lignes de gestion d'EJ aux éOTP, fournies par les centres financiers.

4.4. Le responsable de la comptabilité auxiliaire des immobilisations ministériel.

Le responsable de la comptabilité auxiliaire des immobilisations ministériel, dans son périmètre d'habilitation :

établit et saisit les « règles d'imputation/déversement » des éOTP, de type IA ⁽²⁶⁾, vers les fiches des immobilisations en cours (FIEC) ;
doit être associé à la production de la FIBOC (Fiche d'Imputation BudgétarO Comptable), notamment pour renseigner le numéro de FIEC ; il contrôle la structure, le compte PCE et la nature retenue de l'éOTP ;
effectue les déversements périodiques des éOTP typés IA vers les FIEC.

Le RCAIM est, en général, repéré par un code de service gestionnaire de bien (SGB), positionné dans le paramètre PS « Centre de coûts responsable » (CCR) de l'éOTP.

5. CONTRÔLES.

5.1. Objectifs du contrôle.

Afin de participer à la démarche générale de contrôle interne financier, différents niveaux de contrôle doivent être mis en place dans le cadre du suivi financier des projets.

Les objectifs du contrôle sont de vérifier les stipulations de cette instruction et en particulier l'éligibilité du suivi sur l'axe projet, les structures retenues, le détail et l'exactitude de l'information de gestion fournie, les suivis budgétaire et financier (pré-budgets, valorisation des éOTP et coût global).

5.2. Contrôles de premier niveau.

Durant la vie du projet, les services contrôlent la correcte imputation/référencement de tous les actes de gestion [EJ, ET, SF, DP, OA ⁽²⁷⁾] à leurs éOTP de rattachement et conformément à la nature de la dépense concernée ainsi que la cohérence réciproque des imputations des différents axes de CHORUS.

5.3. Contrôles de deuxième niveau.

Le deuxième niveau de contrôle est dévolu au RPROG qui peut déléguer cette tâche au gestionnaire de projet.

Le RPROG veille en particulier à définir les « consignes d'imputation (de LG aux éOTP) » et à assurer leur cohérence (nature de la dépense/type d'éOTP) ; il en vérifie l'application.

Le RPROG veille à la définition des « consignes d'imputation budgétaires » aux dépenses, et, par conséquent, aux éOTP.

La création des projets est effectuée sous la responsabilité du RPROG. Cette responsabilité consiste à veiller à la validité des renseignements apportés à chaque niveau de la branche du projet de sa responsabilité, en particulier pour les éOTP de type IA, à la présence des paramètres obligatoires des éOTP et à la cohérence réciproque des imputations sur les diverses axes de CHORUS (domaine d'activité, référentiel de programmation, organisation budgétaire, domaine fonctionnel, centre financier, centre de coûts responsable, tranche fonctionnelle, etc.).

Afin de permettre une vision de la soutenabilité de l'ensemble des projets, les pré-budgets peuvent être renseignés pour l'ensemble des projets. Ces informations permettent d'obtenir pour les principaux projets une vision globale des échéanciers participant ainsi à la maitrise de la soutenabilité. Le RPROG assume la responsabilité de la fiabilité et de l'exactitude des données de pré-budget le concernant, saisies dans les projets PS.

Le RCAIM assure les corrects déversements dans les éOTP.

L'entité assurant la « direction d'opération », telle que décrite ci-avant, assure la saisie des pré-budgets la concernant.

5.4. Contrôle de troisième niveau.

La direction des affaires financières est responsable du contrôle de troisième niveau.

A ce titre, elle reçoit les informations qu'elle sollicite de la part des RPROG et des gestionnaires de projet. Elle applique ou fait appliquer les éventuelles corrections d'erreurs par les services, étant entendu qu'il appartient aux services concernés de mettre en œuvre les opérations de corrections adaptées. La direction des affaires financières veille en particulier à l'éligibilité des demandes de création ou de modification des projets.

5.5. Moyens de contrôle.

Les moyens de contrôle mis en place dans ces différents niveaux sont intégrés dans leurs plans d'actions de contrôle interne.

Les requêtes, restitutions et vérifications internes de cohérence du module PS ou de CHORUS sont des moyens de procéder à des contrôles. Les services et la direction des affaires financières ont vocation à établir des procédures simples de contrôle et des documents d'aide à la saisie visant à réduire le risque d'erreurs d'imputation ou de non imputation.

6. EXPLOITATION DES DONNÉES DU MODULE PROJECT SYSTEM DE CHORUS.

6.1. Principe.

Les données enregistrées dans le module PS, dédié au suivi financier, et celles de l'application CHORUS, en tant que système d'information financière de l'État, sont considérées comme données financières de référence du ministère.

6.2. Réconciliation des données des axes de CHORUS via project system (éléments d'organigramme technique de projet).

Le système d'information financière de l'État, CHORUS, comprend un nombre important d'informations portées par des axes ayant des rôles spécifiques.

Il peut en résulter une difficulté à assurer la cohérence réciproque des valeurs de tous les axes.

Dans CHORUS, la présentation de chaque éOTP avec plusieurs onglets portant les informations des axes de CHORUS permet d'y inscrire la valeur de chaque axe pour un même éOTP sur un seul support. Cette « fiche » éOTP, avec ses onglets, donne ainsi la possibilité de capitaliser les informations (dits les « paramètres ») des différents axes CHORUS sur un sujet unique et délimité : l'éOTP. L'éOTP agit alors comme support de synthèse, il donne les liens réciproques entre les axes CHORUS.

Une seule occurrence est possible à la fois par paramètre de la fiche.

Cette possibilité est laissée aux services souhaitant s'en servir sous réserve de tenir à jour les informations portées par les onglets de la fiche éOTP.

6.3. Demande d'évolution des axes de CHORUS.

Les éOTP de fin de structure sont les éléments les plus petits des axes ⁽²⁸⁾ de CHORUS et ils sont trans-annuels.

Toutes les évolutions des axes de CHORUS (activité budgétaire, tranche fonctionnelle, action, sous-action, domaine fonctionnel, centre financier) génèrent un besoin d'harmonisation globale des axes. Les éOTP mettent souvent en évidence des incohérences entre ces axes.

En conséquence, les demandeurs d'évolution des axes de CHORUS sont fondés à accompagner celles-ci des éléments concernés de l'axe projet (projet, branches ou éOTP) quand ceux-ci existent (e.g. création de l'activité budgétaire 0146xxxx incorporant les projets D-Axx-1 et D-Axxx-2) ce qui simplifie l'expression de la demande et son analyse. Les demandeurs d'évolutions des référentiels de CHORUS indiquent les éOTP (ou branches de projets) concernés.

6.4. Référencement des données financières à leurs « biens » de rattachement.

Les données financières « réalisées » sont collectées dans CHORUS avec un référencement à un éOTP (pour les « biens » suivis sous PS).

Ces données, extraites de CHORUS et triées selon l'axe projet (i.e. par code éOTP), affermissent le lien physico-financier entre physique et montants associés au niveau de détail informatif recherché.

Pour les « biens » ayant des pré-budgets saisis sous PS, et sauf exceptions, ces données financières de pré-budgets extraites de CHORUS et triées selon l'axe projet (i.e. par code éOTP) sont celles utilisées pour l'examen des investissements dans les instances de gouvernance des investissements (CMI, CEP, COFI, COFIN, etc.).

En conséquence, les RPROG s'assurent de la tenue à jour des pré-budgets des projets concernés.

Les dossiers de CEP font référence aux codes de projet et éOTP d'appartenance correspondants aux montants libérés.

De même, les dossiers de CMI contiennent la liste des éOTP couverts par le sujet examiné en séance de façon à conserver un lien physico-financier précis.

Les codes sont fournis à un niveau agrégé (sauf cas particulier nécessitant plus de détail), par exemple correspondant aux stades : D-Axxx-A-R pour la Réalisation, D-Axxx-U pour le soutien durant l'Utilisation.

Les écarts significatifs par rapport aux pré-budgets renseignés, pour l'ensemble du projet, par branche ou par éOTP, sont identifiés et expliqués (en particulier dans les documents de programme).

6.5. Règles d'estimation des investissements, avec leurs « biens associés ».

Lors de la décision d'investir, il est présenté à l'autorité une estimation complète du « coût global » de l'investissement ⁽²⁹⁾. Cette estimation couvre l'ensemble des biens participants (donc coûts des « biens associés » inclus).

Les « biens associés », à un bien principal identifié, sont définis comme les biens qui auraient pu être rattachés au projet PS du bien principal mais qui ne l'ont pas été, soit par décision, soit du fait de la « bascule » des projets dans PS.

La présentation avec estimation complète, i.e. du bien principal et des biens associés, est celle utilisée :

pour les passages en CMI ;
lors des franchissements de jalons de stade dans le DOC, le DLR et le DLU.

La présentation avec estimation complète n'est utilisée dans les DS que si le coût global (CG) a évolué par rapport au coût calculé en début de stade [sous réserve des directives relatives au CG et à la gouvernance (IG 1516)].

La présentation du coût global dans le DS n'entraîne pas nécessairement la présentation en CEP de l'ensemble des branches d'un projet multi programmes.

Notes

Estimation réalisée sur la base des informations connues (voire supposées) du moment. 29

Le ministre de la défense,

Jean-Yves LE DRIAN.

Annexes

Annexe I. Compléments sur le suivi financier et project system.

Appendice I.A. Structuration des « projets project system » et éléments d'organigramme technique de projet.

Les éOTP sont rattachés les uns aux autres et regroupés en sous-ensembles ou « branches » assimilables à des sous-projets. Les « éOTP imputables » (i.e. derniers éOTP en bout de branches) constituent les « collecteurs de charges » ⁽¹⁾ élémentaires (et éventuellement de produits issus de recettes non fiscales -RNF-).

L'identifiant de chaque éOTP couvre le périmètre de l'éOTP (éOTP unique en cas d'éOTP de fin de branche, ou périmètre de la branche en cas d'éOTP de tête de branche).

Il est possible de renseigner chaque projet, branche ou éOTP avec des informations, propres à lever des ambigüités, sur son contenu : e.g. objet, délais (début, fin), environnement ou contexte (liens potentiels avec d'autres projets), sous-équipements concernés.

L'organigramme technique de projet (OTP) permet donc de structurer les projets selon un découpage logique représentatif de l'information financière recherchée :

en tenant compte de la décomposition par étape du projet ou stade (préparation, acquisition, utilisation, démantèlement, etc.) ;
en tenant compte des éléments contributifs (infrastructures, centres d'essais, opérations d'armement, etc.) ;
par zone géographique.

Les projets sont structurés selon les niveaux (cf. exemple de structure en annexe V.) :

au niveau 1 : uniquement projet identifié par son nom (du niveau ministère) ;
aux niveaux intermédiaires (niveau 2 jusqu'aux niveaux N -1 non-imputables) :

- les domaines (acquisition, incluant parfois des dépenses ultérieures immobilisables, équipement d'accompagnement rattachable, opérations majeures de rénovation/amélioration utilisation, démantèlement, infrastructure, système d'information et de communication, etc.) ;

- des sous-domaines (exploitation, catégorie de soutien, sites d'infrastructures, etc.) ;

- des périodes temporelles (« stades », des instructions ministérielles ) ;

au dernier niveau N : les éOTP imputables.

Dans ce cas général, les branches de niveau 2 sont spécialisées par programme LOLF. Elles sont ainsi sous la responsabilité d'un responsable de programme (RPROG). Celui-ci est identifié par son code « Gestionnaire de Centre de Profit » (GCP) positionné sur le paramètre « centre de profit » de PS.

Chaque branche du projet ou chaque éOTP imputable est déterminé en fonction du besoin d'information financière nécessaire à son responsable et aux organismes financiers pour suivre le projet.

Un éOTP, ou une branche d'éOTPs, n'a pas de dimensions type prédéfinies (en montant, en durée, etc.), minimum ou maximum, sous réserve de cohérence avec les modèles de projet applicables.

Appendice I.B. Typologie des éléments d'organigramme technique de projet.

Les éOTP imputables, de fin de branches, sont différenciés par type d'éOTP comme suit :

éOTP typé CH : pour les achats stockés ou non stockés (comptes de classe 3 ou 6) et la dette financière relative aux contrats de location- financement ⁽²⁾ (part financement) ;
éOTP relatifs aux dépenses d'immobilisation :
- éOTP typés IE pour les dépenses immobilisées (comptes de classe 2) ou ;
- éOTP typés IA pour les dépenses immobilisables (comptes 23NA, de classe 2) et la dette financière relative aux contrats de location-financement (part investissement) ;
- éOTP typés FA : pour les recettes (comptes de classe 7).

Les autres éOTP d'un niveau supérieur, et donc non imputables, sont typés NI.

Chaque éOTP a vocation à être renseigné avec des paramètres individuels :

centre de profit (CdP, obligatoire pour les éOTP imputables) ;
centre de coûts responsable (CCR, sous son code de service gestionnaire de biens -SGB-, obligatoire pour les éOTP imputables) ;
domaine fonctionnel (DF ⁽³⁾, obligatoire pour les éOTP IA, conseillé pour les autres imputables) ;
centre financiers (CF, obligatoire pour les éOTP IA) ;
domaine d'activité (DA, obligatoire pour les éOTP IA) ;
activité budgétaire (ACT) ;
sans oublier Société, Devise, périmètre analytique (tous obligatoires pour les éOTP imputables) ;
etc.

Appendice I.C. Lien entre type d'élément d'organigramme technique de projet et comptabilité générale.

L'éOTP de type IA est, pour les immobilisations complexes, le support de collecte des dépenses concourant à la valorisation des biens enregistrés en immobilisations, via le déversement des coûts collectés sur les fiches d'immobilisations en cours (FIEC).

L'éOTP de type IA est également le support de collecte des dépenses dans le cadre d'une dette financière relative aux contrats de location-financement (part investissement).

Tous les éOTP doivent être spécialisés par RCAIM « Responsable de la Comptabilité Auxiliaire des Immobilisations » ministériel (via un code de service gestionnaire de bien SGB).

De plus, tous les éOTP imputables doivent être spécialisés par domaine fonctionnel (DF - MPASA, Mission, Programme, Action, Sous-Action) et par comptable (domaine d'activité -DA-).

Le cas échéant, un niveau de regroupement des éOTP d'un même SGB, est créé, dans la structure du projet, par une branche dédiée.

Par ailleurs, l'éOTP de type CH est le support de collecte des dépenses ayant un impact sur les comptes d'achats non stockés et stockés, de stocks et de dette financière relative aux contrats de location-financement (pour la part fonctionnement) en comptabilité générale (comptes de classe 6, 3 et 167).

A l'inverse, l'éOTP typé FA est le support de collecte des recettes ayant un impact sur les comptes de produits en comptabilité générale (comptes de classe 7).

Appendice I.D. Cas des révisions de prix.

Afin que les révisions de prix soient identifiables, en tant que telles, sans confusion, et rattachées au bien-sujet de dépense auquel elles se rapportent (i.e. collectées dans le projet PS du bien), il est utilisé l'un ou l'autre des deux processus suivants :

Processus utilisant l'axe « nature détaillée ministérielle » (processus habituel du périmètre des opérations d'armement) ;
- les RP font l'objet de lignes de gestion spécifiques dans l'engagement juridique ;
- elles sont identifiées par « marquage » dans l'axe « nature détaillée ministérielle » sous le code n° 70-24557000 « Hausses économiques des opérations d'arm. » ;
- elles sont imputées sur un éOTP cohérent avec le type d'imputation de l'acquisition principale auxquelles elles se rapportent.
Processus utilisant un éOTP spécifique RP/HE :
- dupliquer la ligne de gestion subissant la révision de prix ;
- créer l'éOTP spécifique et dédié à côté de l'éOTP concerné ;
- référencer l'éOTP de révision de prix sur la ligne de gestion relative à la révision de prix ;
- Ce type d'éOTP complémentaire porte un code spécifique.

Appendice I.E. Cas des intérêts moratoires.

Les demandes de paiements d'intérêts moratoires (DP d'IM) sont générées automatiquement par CHORUS (sauf en cas de désactivation de la fonctionnalité). Elles reprennent les imputations exactes de la dépense originelle (dont l'éOTP) et sont donc imputées sur le même éOTP que celui de leur ligne de gestion source. Elles sont tracées dans CHORUS par un compte spécifique du PCE (Plan de Comptes de l'État ), n° 6221000000, « Intérêts moratoires ».

Dans le cas d'une demande de paiement d'IM rattachée à un éOTP de type « immobilisés » (IE) ou « immobilisables » (IA), celle-ci porte un compte général de charge (compte de classe 6) alors que l'éOTP correspond à un compte de classe 2 (immobilisation). La DP de classe 6 génère donc une anomalie (éOTP IE ou IA sur compte 6).

Dès lors, lorsque CHORUS génère la DP d'IM, il est obligatoire ⁽⁴⁾ de corriger la DP avant sa validation ; pour cela, l'un ou l'autre des deux processus suivants doit être utilisé :

La DP est corrigée en lui rattachant l'éOTP CH (charge) qui se situe au même niveau d'arborescence que l'autre éOTP (IA ou IE), ou, à défaut, il en est créé un ;
Les montants d'IM sont référencés à un éOTP dédié, portant un code spécifique (dit « éOTP IM »), placé au niveau branche, voire au niveau du projet. Cet « éOTP IM » est limité à un seul programme LOLF.

Dans les deux cas, il appartient au service concerné d'identifier, en amont de la saisie de l'engagement juridique, l'éOTP d'IM concerné rattaché au même niveau d'arborescence que l'autre éOTP IA ou IE.

Cette modalité nécessite en ce sens d'être mise en œuvre dès la production de la FIBOC qui une fois validée par l'ensemble des parties devra être insérée en PJ dans le poste d'EJ et le cas échéant dans la FIEC permettant à l'ensemble des agents des services exécutants couvrant toute la chaîne du WF (Work Flow) de la dépense de disposer des informations nécessaires à la correcte saisie des axes de financement.

Cette correction, obligatoire, dans la pièce de gestion d'IM, facilitée par la saisie en amont dans la FIBOC de l'éOTP CH concerné, permet d'assurer la cohérence comptable et le suivi budgétaire du projet.

Appendice I.F. Cas des pénalités.

Le principe de gestion des pénalités dans CHORUS est le suivant :

Passage d'un Service Fait (SF) de la totalité de la valeur immobilisable (Dt23 Ct408) ;
Passage de la demande de paiement (DP). Celle-ci doit être déclinée en deux lignes de paiement (LP) :
- l'une pour le montant de la facture (elle concourt ainsi à la valorisation de l'immobilisation) avec le code éOTP concerné ; donc, paiement de la part hors pénalité (Dt408 à Trésorerie pour simplifier) ;
- l'autre pour la pénalité (elle ne concourt pas à cette valorisation mais elle diminue le net à payer) avec, toujours, le code éOTP concerné. Il est utilisé pour l'expression de la pénalité au statut provisoire [« pénalité provisoire », avec une écriture en classe 4 : comptes PCE 4016 et 4046 (pénalités charges et immos)]. Ainsi, le montant de la pénalité n'est pas réglé mais comptabilisé en compte 4016 ou 4046.

Par la suite, le paiement de la pénalité est soit confirmé, soit exonéré.

Si la pénalité est confirmée, alors une écriture Dt 4016 Ct 722 est comptabilisée (pièce KN) et le produit de la pénalité (en classe 7) est constaté sur un éOTP « produit » typé FA (éOTP de pénalité) spécifique (dit « éOTP pénalités ») ; cette opération contrepasse l'écriture de la pénalité provisoire (en classe 4) sur l'éOTP d'origine ;
Si la pénalité est levée, alors son montant est réglé au fournisseur (pièce KP) ; la DP porte le code éOTP de la DP d'origine. L'exonération n'a pas d'effet sur l'écriture de pénalité provisoire, elle ne fait qu'ajouter une dépense sur l'éOTP d'origine.

Ainsi, les pénalités confirmées alimentent un éOTP « produits recettes » de type FA dédié. Cet éOTP est en général au niveau du stade. Ce type d'éOTP complémentaire porte un code spécifique. Au regard de ce schéma d'écritures il doit être noté que la FIEC est valorisée depuis l'étape 1, le suivi de la pénalité étant sans incidence sur la valorisation de la FIEC, a fortiori de la FIES.

Appendice I.G. Processus de création/modification de projet ou éléments d'organigramme technique de projet.

a) Initialisation et demande.

L'entité chargée de la conduite du contenu (réalisation, soutien, DUI, etc.) de l'éOTP (dite ici « conduite d'opération ») ou le centre financier ⁽⁵⁾ [RPROG, RBOP ou RUO ⁽⁶⁾] initialise la demande auprès de la direction des affaires financières par courrier ou messagerie électronique en utilisant le formulaire type décrit en annexe « éléments devant être renseignés pour un projet PS et un éOTP ».

Cette demande est accompagnée :

d'une proposition de structure du projet fondée sur l'une des « structures types » ou du code d'un projet existant à copier ;
des informations de paramétrage du projet et des éOTP ;
du nom, concis, de l'investissement (ou du « sujet » de dépense) et d'une brève explication de celui-ci permettant d'évaluer la nécessité de créer un nouveau projet ou de le rattacher à un projet existant ⁽⁷⁾.

b) Analyse, validation initiale et création de l'éOTP « de tête ».

La direction des affaires financières exerce un contrôle de la demande (éligibilité, structuration, analyse financière, contrôle de forme de la demande, projets similaires existants, choix du « modèle de projet applicable » adéquation structure/projet, etc.).

La direction des affaires financières échange avec le demandeur et le (ou les) responsable(s) de programme concerné(s) ou leurs représentants afin d'obtenir les précisions nécessaires.

La direction des affaires financières valide la structure et autorise le demandeur à créer la structure dans les limites validées.

Après validation la direction des affaires financières crée sous PS le projet jusqu'à l'éOTP de « tête de branche » confiée à la conduite d'opération (avec attribution du code et création du nom de projet ou d'éOTP). Elle en informe le demandeur, avec ses remarques et demandes complémentaires.

L'éOTP de tête passe au statut « ouvert ⁽⁸⁾».

c) Création de la structure sous l'éOTP « de tête ».

La conduite d'opération ou le centre financier, sur sollicitation du responsable de programme (RPROG) ou selon les procédures et délégations internes du programme, crée les éOTP inférieurs à celui de tête créé par la direction des affaires financières. Elle saisit les paramètres de tous les éOTP puis informe la direction des affaires financières de la fin de ces opérations, via son responsable de programme.

Les éOTP créés sont au statut « ouvert ⁽⁹⁾ ».

d) Vérification.

La direction des affaires financières vérifie les compléments apportés par la conduite d'opération et examine les éventuelles modifications demandées pour la partie « en tête ».

La direction des affaires financières passe alors le projet au statut « validé ⁽¹⁰⁾».

e) Lancement.

Lorsque le responsable de l'opération ou le responsable de programme souhaite que le projet fasse l'objet d'imputation, il demande à la direction des affaires financières de passer le projet ⁽¹¹⁾ sous le statut « lancé ⁽¹²⁾».

Le projet/l'éOTP ou les modifications sont dès lors actifs.

f) Saisie des règles de déversements.

Le responsable de la comptabilité auxiliaire des immobilisations, saisit les règles d'imputation/déversement.

Les éOTP concernés passent au statut système « règle d'imputation saisie⁽¹³⁾».

Appendice I.H. Processus de création de branche spécifique à un service gestionnaire de biens ou à un responsable de la comptabilité auxiliaire des immobilisations ministériel (cas dérogatoire).

Le responsable de programme « receveur » construit le détail de la branche nouvelle (selon la structure agréée par l'autorité) jusqu'à l'emplacement (dit « point d'accrochage ») où doit s'implanter la nouvelle branche confiée au RCAI « incident ».

La direction des affaires financières valide l'évolution et donne l'autorisation temporaire, au service agissant comme RCAIM ou SGB « incident », d'effectuer les modifications autorisées. Pour cela, elle positionne le code de centre de profit, dont dépend le RCAIM ou SGB « incident », sur la « définition de projet ».

Le service incident installe sa structure spécifique au « point d'accrochage » indiqué (sauf si déjà fait par le responsable de programme) conformément à sa structure agréée (en général la structure type habituelle de travail du service exécutant). Il en renseigne les paramètres des éOTP.

Appendice I.I. Processus de clôtures d'éléments d'organigramme technique de projet ou de projet.

Lors des opérations de clôture, un dialogue est engagé entre les responsables de programme concernés et la direction des affaires financières pour recueillir et enregistrer leurs avis sur les fermetures envisagées.

Lors de sa fermeture, le projet ou l'éOTP est d'abord passé au statut « clos techniquement ⁽¹⁴⁾ ». Ce statut empêche d'y imputer de nouveaux engagements juridiques mais permet de terminer le processus engagé de dépenses et d'y imputer des coûts.

Les projets et éOTP sont clos ensuite par passage au statut « clos comptablement ⁽¹⁵⁾ ». Ce statut interdit l'imputation des coûts. Ce statut est toutefois réversible, son annulation se traduisant par un retour au statut « clos techniquement ». L'annulation de ce statut fait l'objet d'un cycle d'échange entre la DAF et l'entité concernée, à l'instar de celui décrit ci-avant pour la clôture.

Notes

Statut TCLO sous PS.14

Statut CLSD sous PS.15

ANNEXE II. Structures et codes.

Appendice II.A. Les structures des « projets project system ».

Au niveau 1 de la structure, chaque projet PS d'équipement désigne :

son rattachement au MinDef (par le code : « D- ») ;
sa nature d'équipement/Armement (« A ») ;
l'équipement lui-même (par un numéro à 3 chiffres, fourni par CHORUS, et un « tiret »).

Le tout apparaît sous le code : « D-Axxx- ».

La structure des projets d'armement suit ensuite la découpe en « stades », parfois regroupés par « phase », dans des branches ou sous-branches dédiées :

Phase « Préparation », subdivisée en sous-branches : Initialisation et Orientation :
- D-Axxx-A-B- pour le stade d'Initialisation ;
- D-Axxx-A-A- pour le stade d'Orientation ;
Phase « Acquisition », subdivisée en sous-branches : Elaboration et Réalisation :
- D-Axxx-A-C- pour le stade d'Elaboration ;
- D-Axxx-A-R- pour le stade de Réalisation ;
Stade « Utilisation », identifiant séparément ce qui relève de l'« Exploitation » et ce qui relève du « soutien » :

- D-Axxx-U- pour le stade d'Utilisation ;

Stade « Démantèlement », subdivisé par stade (si existant) : Initialisation, Orientation, Elaboration et Réalisation :
D-Axxx-D- pour le stade de Démantèlement.

Nota. Le tiret après D-Axxx-B ou A ou C ou R ou U ou D est réservé.

La structure des projets d'armement inclut également, en les identifiant séparément dans des branches ou sous-branches dédiées :

Les « opérations majeures de rénovation et/ou évolution » ; subdivisées par stades amont, et selon besoin : Initialisation, Orientation, Elaboration et Réalisation :
- D-Axxx-(1 chiffre)- ;
- Les codes suivants peuvent aussi être utilisés :
  - D-Axxx-EV- pour EVolutions ;
  - D-Axxx-TO- pour Traitements d'Obsolescences ;
  - voire D-Axxx-EVTO- pour « Evolutions et Traitements d'obsolescences » ;
Les « opérations d'armement d'environnement » spécifiquement rattachables au bien sujet du projet, subdivisés par stades amont, et selon besoin : Initialisation, Orientation, Elaboration et Réalisation :
- D-Axxx-V (éventuellement indicé Vi avec un chiffre) ;
Les « infrastructures » spécifiques à l'équipement :
- D-Axxx-I- pour les Infrastructures associées spécifiquement à l'équipement.

A partir de ces rangs, peuvent être éventuellement ajoutés des niveaux représentant des informations signifiantes, dont une partie est indiquée ci-après et concerne essentiellement le soutien en service.

Au-delà des rangs ci-dessus, les branches des projets PS d'équipement sont actuellement et en général découpées par service exécutants (SE). Les branches D-Axxx-U et D-Axxx-I ne sont pas concernées et suivent des décompositions spécifiques.

Il convient de noter que ce regroupement par SE n'est pas une contrainte technique mais une pratique actuelle qui a vocation à disparaitre au profit d'un mode de regroupement par Service Gestionnaire de Bien (SGB) d'éOTP d'immobilisation. Un éOTP est limité à un seul SGB ; peuvent y imputer tous les organismes que le SGB y accepte, sauf pour les éOTP de type IA. Ces imputations doivent toutefois avoir les mêmes paramètres que l'éOTP et en particulier avoir le même centre de profit.Au rang suivant, se trouvent les éOTP imputables par les lignes de gestion d'engagements juridiques (LG d'EJ), donc en fin de branches, différenciés, a minima, par type d'éOTP : CH pour Charges, IE pour Immobilisé et IA pour Immobilisable.

Tous les autres cas de structures sont des cas dérogatoires requérant l'agrément de l'administrateur du référentiel des projets et éOTP.

Appendice II.B. Les codes des « projets project system » et des éléments d'organigramme technique de projet.

Ce paragraphe ne reprend que les éléments dont les codes n'ont pas été déjà fournis dans le paragraphe « Structures des projets PS » supra.

1 Principe général et règle de codage.

Chaque projet ou éOTP est identifié individuellement par un code alphanumérique unique.

La codification a pour but d'assurer la cohérence d'ensemble du référentiel des projets et éOTP. Tous les codes des projets et éOTP ont vocation à répondre à une logique et à une cohérence sémantique d'ensemble. L'objectif est de simplifier et d'harmoniser la lecture de la signification des codes.

La codification des éOTP est du ressort de la DAF. En particulier, l'emploi des lettres, chiffres et/ou signes, seuls ou groupés, est fixé par la direction des affaires financières. Les premiers niveaux de la structure sont imposés par la DAF pour des raisons de cohérence d'ensemble et de lisibilité unique par type de projet.

Compte tenu du nombre limité de caractères pour installer le code, l'administrateur peut être amené à imposer une partie du libellé de l'éOTP (exemple : commencer le libellé par le site géographique (ex : BA113) pour un éOTP d'infrastructure).

Pour tous les autres cas, il est nécessaire de faire appel et de faire valider la structure et/ou les codes par l'administrateur du référentiel des projets et éOTP.

2 Constitution du code.

La codification des projets et éOTP est composée de blocs signifiants de caractères. Ces blocs correspondent en général aux rangs des éOTP.

Le code de chaque éOTP reprend le code de l'élément directement supérieur (code du projet pour l'éOTP de niveau 1, code de l'éOTP directement supérieur pour les autres éOTP) auquel sont ajoutés un séparateur « - », en général, et un code signifiant et discriminant.

3 La codification des éOTP de rang 1.

Le premier bloc identifie le ministère et le projet classé par type. Il correspond aux éOTP de rang 1. Sa codification comporte 7 caractères. Elle est du type « D-Lnnn- » (avec Lnnn pour une Lettre et 3 chiffres).

4 Codification des éOTP « avals ».

En partie aval de la structure se trouvent les éOTP imputables, actuellement, regroupés par SE ⁽¹⁾ :

éOTP (non imputables) désignant le SE ;
Codification :
- Les SE sont codés par deux caractères (hors tirets) sauf exception ;
- Le détail de ces codes est donné dans un document dédié ;
éOTP imputables :
- Les éOTP imputables sont codés sur 1 à 2 caractères, hors tiret, sauf exceptions ;
Codification :
- Le premier caractère précise le type d'éOTP (paramétré par ailleurs) ; pour cela, ce caractère correspond au code du « type d'imputation » (même codification : Z, Y, V, S, W). Ce code est imposé. Cette lettre code peut être suivie d'un indice (2^ème caractère). La signification de certains de ces binômes [type d'imputation et indice] est imposée ; ceux-ci ne doivent alors être employés que conformément à leur signification ;
- Un deuxième (et unique) caractère peut-être ajouté ; soit en référence à la codification standardisée ; soit sous forme d'indice (par exemple : -Zi ou -Za) gérés par le SE.

Le détail de ces codes est donné dans un document dédié.

5 La codification des éOTP intermédiaires (entre éOTP de rang supérieur à 1 et éOTP « aval »).

Entre les niveaux supérieurs et les branches dédiées de SE, la structuration, et la codification associée, reproduisent le besoin de suivi des autorités, des acteurs hiérarchiques (RPROG, EMx) ou locaux (BOP/RUO/ SSx…) : par armée, par sous-catégorie d'actif, conventionnel/nucléaire, etc.

Quand la variété des cas suivis le nécessite (suivi par armée de matériels communs), la codification des SE de l'entretien courant remonte d'un cran faisant ainsi disparaître l rang entretien courant (S-) en tant que tel.

La codification des éOTP de rang supérieur à 1 suit des règles de codification différentes selon les types de projets (armement, infrastructures, SIC, etc.) et les branches dans lesquelles ils sont implantés.

Appendice II.C. Compléments et cas particuliers de structure et de code.

1 Complément sur la codification des éOTP de rang 1.

Tous les projets sont du ministère sans autre identifiant d'acteur intra-ministère. Tous les codes, de projets comme d'éOTP, du ministère commencent par deux caractères [D-] identifiant le ministère de la défense.

Détail des lettres codes de premier rang.

D.	-.	L.	nnn.	-.
Ministère de la défense		Type de projet	n° incrémental sur 3 chiffres	(tiret séparateur)
Obligatoire		Lettre cf. ci-après		Obligatoire

L : correspond à une lettre d'identification du type de projet :
- A : pour « Armement », utilisée pour les projets relatifs aux équipements militaires ;
- C : pour les projets SIC ;
- D : pour les projets de renseignements spécifiques (DGSE) ;
- E : pour « Essences » utilisée pour les projets SEA ;
- F et G : pour les projets du FRED ;
- F : pour les projets commencés avant 2009 ;
- G : pour les projets commencés après 2009 ;
- H : pour « divers, hors investissements » ;
- I : pour « Infrastructure », utilisée pour les projets du SID ;
- J : pour divers (SPAC, etc.) ;
- K : pour les sites, établissements et organismes ;
- M : pour « Modèle » de projets ;
- T : pour divers Energies et autres... (code à privilégier pour les « divers » ;
- X : pour les OPEX ;
- Y : pour les projets extérieurs au ministère de la défense (DGGN, DDI...) sur lesquels il est demandé au ministère d'intervenir.

Toutes les autres lettres sont réservées.

Pour les projets SIC, des tranches de numéros peuvent identifier le type de SI ou l'organisme :

--C001 à D-C999) = SIAG ou BOP SIC,

--au-delà de D-C1000 = SIOC (réservé).

2 Cas particulier de la codification des branches dédiées de SE.

Les service exécutant (SE) imputant les branches dédiées par SE ⁽²⁾ utilisent une structure type agréée.

Certaines structures dédiées de SE sont données dans les planches qui suivent.

Chaque structure débute par un éOTP de type NI encapsulant les éOTP imputables dédiés.

Le code est limité à 7 caractères, il identifie :

le SE sous 2 caractères (sauf cas particuliers) ;
la catégorie d'achat (prestations, autres charges, stocks, encours/immobilisable, immobilisé, montant historique) sous 2 à 3 caractères sauf les éOTP IA le nécessitant.

Des cas particuliers existent (résolution du projet temporaire PIVOT, etc.). En général, ils sont codés de façon significative pour éviter une confusion avec les cas généraux.

3 Cas de la branche « U » d'un « bien » précis.

Les branches « Utilisation » des équipements militaires sont structurées selon le milieu concerné.

Après l'actif patrimonial ⁽³⁾ codé D-Axxx-, sur 7 caractères) et la désignation de la branche U (codée U-, sur 2 caractères, pour l'Utilisation), les informations complémentaires identifiées (ou simplement différenciées) dans le code des éOTP en branche D-Lxxx-U- sont :

la catégorie de soutien :
- soutien/entretien courant (codé S-) ;
- grande visite n° i (codé Vi) ;
- opérations majeures de rénovation/évolution n° i, (codé Pi) ;
- exploitation/service (codé ES) ;
- recettes (codé R), sur 2 caractères ;

dans certains cas, l'armée ou l'organisme détenteur du matériel : MN, AdT, AA, SEA, SSA... ;
dans ceratins cas, le domaine fonctionnel (MPASA) : (ex : 0178-03-48), 10 caractères réduits à 4 caractères maximum.

La fin du code suit les règles générales avec le service exécutant (Se) et la catégorie d'achats.

4 Cas spécifiques à certains SE.

Le code du SE SID incorpore le code PLIMAT, ou COSI, dans les branches concernées.

Le SE DGA compte trois structures spécifiques DGA_OA opération d'armement et DGA_OT opérations techniques et le SE DGA Washington.

5 Codification des éOTP intermédiaires.

Entre les niveaux supérieurs et les branches dédiées de SE, la structuration et la codification associée, reproduisent le besoin de suivi des autorités, des acteurs hiérachiques (RPROG, EMx) ou locaux (BOP/RUO/SSx...) : par armée, par sous-catégorie d'actif, conventionnel/nucléaires, etc.

Quand la variété des cas suivis le nécessite (suivi par armée de matériels communs), la codification des SE de l'entretien courant remonte d'un cran faisant disparaître le rang courant (S-) en tant que tel.

6 Cas particulier de prise en compte du DF (4) (ou MPASA).

Il peut être nécessaire de différencier des éOTP en fonction des domaines fonctionnels (par exemple : éOTP typé IA nécessaitant d'être distingués par DF/MPASA).

En ce cas, le domaine fonctionnel (MPASA) est alors donné par une lettre et deux chiffres (hors tiret) :

la lettre correspond à (concernant les principaux codes) :
- F pour la Marine ;
- T pour l'AdT ;
- A pour AA ;
- G pour EMA ;
les deux chiffres sont les deux derniers chiffres du numéro de MPASA complet.

Exemple : F07 pour 0178-03-07 « MCO du matériel des forces navales ».

Une partie du DF peut recouper le centre financier ou l'armée.

En branche « -U- », le code est inséré au niveau de l'armée détentrice (désignée sous la même forme codée ci-dessus : F pour Marine, T pour AdT, etc.) suivie des deux derniers chiffres du DF/MPASA (par exemple pour 0178-03-48, de la Marine, les deux derniers chiffres sont repris dans le code de l'éOTP, de la branche P178, à la suite du code Marine (F) ce qui donne : F48).

Nota. Ceci est un cas particulier de la structure.

7 Cas particulier des caractères réservés.

Des réserves ont été aménagés dans le code pour pallier les cas imprévisibles (tiret supplémentaires ou modifiables, code suppressibles, etc.).

Pour cette raison, il est interdit de mettre un chiffre après les lettres : -P, -A, -V, -U, -D, -I (qui sont, en général, au rang 2).

8 Cas du séparateur « tiret ».

Le séparateur « tiret » peut être remplacé par un chiffre ou une lettre. Il s'agit d'une pratique dérogatoire à la règle.

Exemple : D-Axxx-U- est en général financé par le P178 (cas régulier). En cas de financement par le P146, il y a alors obligation d'une branche spécifique (-U, financé par le P146) et le code de cette nouvelle branche devient alors D-Axxx-U6, avec suppression du tiret si nécessaire ⁽⁵⁾ pour indiquer le caractère dérogatoire et le programme de financement (6 pour P146, 4 pour P144...).

Les « - » conservés, à compter du rang 2, sont uniquement ceux réservés à d'autres informations (absentes dans le cas général) et aux cas dérogatoires. Ces dérogations aux règles de codification et quelques particularismes sont identifés en remplaçant les « - » par d'autres informations, par exemple : financement de la branche par des crédits autres que ceux du programme LOLF habituel ; le « - » est alors remplacé par le chiffre final du Programme LOLF financeur).

Le premier tiret de D-Xxxx n'est jamais supprimé.

9 Cas spécifiques du code « -I » et des infrastructures.

Le code « -I » est strictement réservé aux INFRAS.

Les codes des éOTP d'infra incorporent les numéros PLIMAT ou COSI, dans les branches concernées, y compris dans les branches des stades amonts des équipements (par exemple : Élaboration, réalisation... du type D-Annn-A-R-I-PL-pppppp-).

10 Cas spécifique dérogatoire pour la DGA en tant que SE.

La DGA a des structures spécifiques de SE pour DGA_OA « opération d'armement » et DGA_OT « opérations techniques » et « DGA_WA pour DGA Washington » avec une codification propre à ces SE.

De même, les éOTP imputables des SE DGA suivent une codification propre.

11 Cas particulier des « indifférenciés ».

Dans ceratins cas, il n'est pas utile, ou il n'est pas possible, de suivre les coûts au niveau de détail requis (par exemple, par SE). En ce cas, ces dépenses sont dites « indifférenciées ». Les indifférenciés peuvent concerner des stades, des équipements (dans une certaine mesure, par exemple des études communes), des SE ou autres généralement pourtant identifiés. Ils ne peuvent pas concerner des types d'éOTP.

Les éOTP indifférenciés ont une codification spécifique : « 00 », hors tiret.

Les éOTP indifférenciés sont placés au même niveau dans l'arborescence que les éOTP « différenciés ».

12 Cas particulier des projets D-A9xxx.

Les projets D-A9xx, avec 9xx supérieur à 905, sont des projets « de dernier ressort ». Leur usage est limité aux biens qui ne nécessitent ps un projet en propre et pour les dépenses qui ne sont pas bien (dépenses indivises).

Compte tenu de leurs structures particulières, les projets D-A9xx disposent des codifications spécifiques et adaptées traitées au ca par cas en liaison avec la DAF.

Annexe III. Éléments devant être renseignés pour un projet project system et un élément d'organigramme technique de projet.

Télécharger le fichier

Annexe IV. Pré-budgets.

1. Complément relatif à la fonctionnalité « pré-budgets ».

Les divers pré-budgets diffèrent entre eux principalement par leur maille temporelle (année, stade, etc.), leur maille physique (projet, branche, groupe d'éOTP, éOTP individuel), leurs dates d'occurrence (e.g. année d'engagement, mois de paiement, année de ressources, année de besoin d'AE, etc.), leur permanence ou leur mise à jour ainsi que sur des éléments techniques : leur type de crédits (AE, CP, montants) et leur caractère courant ou constant. Chaque éOTP peut être doté d'un pré-budget.

Le « Coût global » doit être apprécié « à terminaison » et dans les conditions connues du moment.

Le module PS (Project System) permet de saisir 8 tableaux prévisionnels ou échéanciers (dits « versions » de pré-budget) qui sont détaillés ci-dessous.

Le nombre maximal d'exercices comptables annuels pour lesquels une pré-budgétisation est possible est de 20 années glissantes :

a) c'est-à-dire que l'année A1, il est possible de pré-budgéter les années A1 à A20 ;
b) et dès l'année A1 +1 (ou A2), l'année A21 pourra être pré-budgétée.

Afin de conserver l'exhaustivité de la prévision, la dernière année (année 20) consolide le solde des coûts prévisionnels restant (année 20 et au-delà).

Chaque pré-budget est accompagné d'information textuelle permettant d'améliorer son appréciation et sa pertinence (ou de préciser son origine : e.g. « source : sortie de VAR 20xx »).

2. Les quatre versions de pré-budgets.

Les versions de pré-budget sont les suivantes [avec correspondances en CHORUS].

2.1. La première version de pré-budget sert lors de la décision des autorités de lancer le programme.

Elle permet d'enregistrer le montant total des impacts financiers du projet, sur toute sa durée de vie, tel qu'il était évalué lors de la prise de décision des autorités de lancer l'investissement. Cette version est appelée VIDI (Version Initiale de décision d'Investissement).

Cette version constitue le coût de référence du projet et, en conséquence, ne sera plus modifiée. La comparaison de cette prévision avec la consolidation des dépenses effectives, sur tous les éléments du projet, et financées par tous les programmes LOLF concernés, permettra une analyse globale des coûts de l'ensemble de l'investissement sur sa durée de vie. L'analyse statistique des données par famille d'équipements permettra en outre d'affiner les prévisions des investissements ultérieurs, en particulier d'améliorer la connaissance des ratios internes d'investissement.

Le périmètre couvert concerne :

le bien sujet de l'investissement (e.g. équipement, infra, logiciel, etc.) aussi bien durant ses phases « amont » d'obtention que ses phases « aval » d'utilisation (soutien inclus) et de retrait du service, en incluant ses grosses opérations d'évolutions (Rénovation à Mi-Vie, etc.) ;
ses éléments « latéraux » nécessaires à son plein effet (e.g. Infrastructure pour un équipement, équipement d'accompagnement, etc.).

Cette version comporte un « montant » unique par stade ⁽¹⁾ (i.e. ni AE, ni CP).

Elle est en euros constants d'une année de référence (dits : euros constants datés).

2.2. La deuxième version de pré-budget concerne le stade à lancer du projet.

Elle conserve la prévision des engagements d'une part (en AE), et de paiements d'autre part (en CP), fournie au lancement du stade. Elle constitue la cible pour le stade et n'est donc plus modifiée durant le stade. Cette version est appelée VCGF (version de Cible Glissante Financière).

Elle a vocation à identifier les écarts « prévu/réalisé » durant le stade et à prévenir les dérives financières.

Cette version est en AE, d'une part, et en CP, d'autre part avec un chiffre par année du stade et un seul chiffre pour les stades ultérieurs. Les stades antérieurs ne sont jamais repris, comme c'est le cas pour toutes les prévisions. La mise à jour de cette cible intervient uniquement au départ d'un nouveau stade et uniquement pour les stades à venir (débutant et ultérieurs), par phénomène de « glissement ».

Elle est en euros courants de l'année d'engagement pour les AE. Elle est en euros courants de l'année de paiement pour les CP.

Les deux dernières versions de pré-budgets, présentées ci-dessous, permettent de confronter sur le même outil financier les prévisions, mises à jour, de besoins et de ressources financiers. Sont ainsi exprimés, dans CHORUS et de façon dynamique, d'une part les besoins en crédits nécessaires et d'autre part les ressources allouables, pour le stade, voire au-delà.

2.3. La version de pré-budget affichant la mise à jour des besoins de ressources dans les années à venir.

Cette version est appelée VDEB (Version Dynamique d'Expression de Besoins).

Elle permet à la direction de projet d'afficher ses prévisions de besoins annuels d'AE et de CP, à obtenir en PLF annuels (et non pas ses besoins d'AE pour engagement).

La mise à jour doit, a minima, être annuelle dans le cadre de la VAR (avec les chiffres de sortie de VAR) le cas échéant actualisée lors d'un passage en CEP ⁽²⁾ ou en CMI ⁽³⁾ par les données de l'exercice en cours telles que résultant du DPG ou du suivi de gestion.

2.4. La version de pré-budget affichant la mise à jour des possibilités d'allocation de crédits, autrement dit la répartition prévisionnelle de ceux-ci par année à venir.

Cette version est appelée VDER (version Dynamique d'Expression de Ressources).

Cette version de pré-budget permet de mettre à jour les allocations annuelles de ressources, en AE et en CP, à venir en PLF.

La mise à jour sera faite au minimum à l'occasion des actes de gestion suivants : (sortie de VAR et SG2).

La comparaison des expressions dynamiques de besoins et de ressources (VDEB et VDER) permet d'apprécier l'écart entre besoins demandés et ressources allouables.

Ces chiffres consolidés au niveau adéquat, par exemple programme LOLF ou agrégat équipements, permettent de vérifier le maintien du niveau maximal engageables (AE)/ payables (CP) de chaque année ; ce maintien est obtenu par compensation des besoins d'un programme d'acquisition vers un autre.

3. Complément d'informations pré-budgets.

3.1. VIDI (Version Initiale de Décision d'Investissement).

C'est l'estimation initiale ayant supporté « la décision d'investissement » :

[PS1] en montants (assimilables à des AE) ; en euros constants datés, saisis par stade (1 chiffre par stade). Son information textuelle d'accompagnement précise ses conditions d'élaboration, par exemple, la chronique d'évolution annuelle des indices ayant permis d'établir ces montants (e.g. cf. DOC n° xxx du dd/mm/aaaa) ;
[PS5] réservé.

Ces informations doivent permettre de recalculer l'échéancier de prévision en euros courants tel que projeté à date initiale de saisie.

3.2. VCGF (Version de Cible Glissante Financière).

C'est la référence financière du stade en cours (et une estimation des suivants) :

en AE et en CP ; euros courants, par année du stade ; par stade au-delà ;
à date (année) d'engagement (AE), de paiement (CP).

3.3. VDEB (Version Dynamique d'Expression de Besoins).

C'est l'expression des besoins financiers du projet :

en montants (assimilables à des AE) ; euros courants, par année du stade ; par stade au-delà ;
à date (année) de besoin d'AE, de CP, à exprimer en PLF.

3.4. VDER (Version Dynamique d'Expression de Ressources).

C'est l'expression des ressources financières disponibles pour le projet :

en montants (assimilables à des AE) et en CP euros courants, par an du stade, par stade au-delà ;
à date (année) d'allocation d'AE, de CP, en PLF.

3.5. Table d'évolution prévisionnelle.

La règle monétaire de valorisation (table d'évolution prévisionnelle annuelle de l'indice d'actualisation des montants) de chaque version de pré-budget, ainsi que les références des documents définissant le contenu relatif à ces pré-budgets (références de FCMR, DS, etc.) sont transmises à la DAF et attachées en pièce jointe dans la définition de projet. Pour la VIDI, elle peut être saisie sur la version libre (PS5).

3.6. Cas des « fourchette de valeurs ».

Lorsqu'une fourchette de valeurs est présente dans le document source, le montant incorporé dans PS peut être circonstancié en insérant une information textuelle (commentaire précisant les hypothèses ou l'intervalle, du type : estimation haute, estimation basse, estimation médiane, à plus/moins x M euros près, etc.). Il peut utilement être rajouté une pièce jointe à ce sujet au niveau du projet.

4. Caractéristiques comparées des types de pré-budgets.

NOM. (PSi)	MONNAIE EUROS.	AE, CP, AUTRES.	MAILLE TEMPORELLE.	HORIZON TEMPOREL.	DATE.	MAILLE PHYSIQUE.	REMARQUE.
VIDI PS1	euros constant	montants	stade	vie	1^ère année de besoin	stade	obligatoire
PS5	réservé	-réservé-	-réservé-	-réservé-	-réservé-	-réservé-	-réservé-
VCGF PS2	euros courant	AE	« année pour le stade en cours et stade au-delà »	stade	année d'engagement	stade	obligatoire
PS6	euros courant	CP	« année pour le stade en cours et stade au-delà »	id	année de paiement	stade	obligatoire
VDEB PS3	euros courant	AE		stade ou +	année de besoin d'AE	stade	obligatoire
PS7	euros courant	CP		id	année de besoin de CP	stade	obligatoire
VDER PS4	euros courant	AE		stade ou LPM	année d'allocation	stade	àd
PS8	euros courant	CP		id	id	stade	àd
àd = à disposition. Id = idem

Annexe V. Modèles de structures des projets sous project system.

1 Structure de base au niveau imputable pour les services exécutants (hors SE DGA).

Cette structure présente les niveaux imputables et leurs codes. Les lettres conventionnelles désignant les « types d'imputation » sont reprises.

(Après la ligne supérieure hors structure, indiquant le « point d'accrochage »). La première ligne indique le service exécutant (codé LL).

TYPE.	RANG.	CODE.	FIN DU CODE.	DÉSIGNATIONS INDICATIVES.	REMARQUE.
NI	n -1	s. o.		« point d'accrochage »	actif_phase _stade_niveau de détail concerné (ndc) (voir R1.)
NI	n	-LL		(Informations amonts)-SE LL	Branche dédiée au SE LL ; LL = identifiant du SE. (voir R1 et R2.)
IE	n +1	-LL	-Yi	(Info. amonts)-LL-Immobilisé	dépenses comptables d'immobilisation simple, pour les "immobilisés" (IE), "type d'imputation" Y.
IA	n +1	-LL	-Vi	(Info. amonts)-LL-Immobilisable	immobilisation complexe (encours 23NA), des « immobilisables » (IA) "type d'imputation" V. (cf. R4.)
CH	n +1	-LL	-Zi	(Info. amonts)-LL-Charges générale	charges comptables (« type d'imputation » Z) à caractère de prestations ; ( -Z : par défaut, autorisé) ; (voir R3.)
CH	n +1	-LL	-ZP	(Info. amonts)-LL-Prestations	charges comptables (« type d'imputation » Z) à caractère de prestations ; (voir R3.)
CH	n +1	-LL	-ZR	(Info. amonts)-LL-Réparations	charges comptables (« type d'imputation » Z) à caractère de prestations de Réparation ; (voir R3.)
CH	n +1	-LL	-ZC	(Info. amonts)-LL-Autr. Charges	charges comptables (« type d'imputation » Z) pour les autres charges. (voir R3.)
CH	n+1	-LL	-Wi	(Info. amonts)-LL-stk p GM	"achats" stockés, par GM (« type d'imputation » W) (i : option, si besoin) ( -Zi : par défaut, autorisé)
CH	n +1	-LL	-Si	(Info. amonts)-LL-stk p Article	"achats" stockés, par Article (article connu) (« type d'imputation » S) (i : option, si besoin) (-Zi : par défaut, autorisé)
CH	n +1	-LL	-RP	(Info. amonts)-LL-RevPx-HE	charges comptables relative à des révisions de prix (aussi dites « hausses économiques »).
CH	n +1	-LL	-Hi	(Info. amonts)-LL-Autr.Charges	Montants historiques (Réservé DAF)
CH	n +1	-LL	-FA	(Info. amonts)-LL-Autr.Charges	Recette -- code à confirmer. --

GM : Groupe de Marchandises

L'indice (i) est optionnel ; il est employé en cas de besoin de différenciation d'éOTP du même type d'imputation (même lettre finale).

Le premier « tiret » est réservé. La suppression du 2^nd tiret est réservée.

Les « Info amonts » sont du type : D-Lxxx-phase-stade-…….. (exemple : D-Lxxx-A-R)

Remarques :

(R1) Le RPROG de la branche d'accueil indique l'éOTP du niveau supérieur ("n-1" ci-dessus), où installer la branche dédiée du SE (dit « point d'accrochage »).

(R2) Cet éOTP est la « tête de branche » du SE. Elle encapsule toutes les dépenses par le SE et uniquement par ce SE à ce point de la structure.

(R3) Retrait, réservé, de "Z" en cas de besoin.

(R4) Pour les éOTP typé IA, en cas de besoin de différentiation de ceux-ci par code PCE, les lettes finales « -Vi » peuvent être remplacés par le code PCE concerné moins le début « 23 » qui est commun : exemple : « -1974 » pour l'éOTP IA à code PCE 231974.

La liste des services exécutants codés (hors SE DGA) avec leur code est donnée ci-après.

CODE LL =	ENTITÉ.	DIRECTION.	REMARQUES.
SSF	SSF		(mnémonique) Soutien Flotte
ST	SIMMT		(mnémonique) Soutien Terrestre
SA	SIMMAD		(mnémonique) Soutien Aéro
SM	SIMMU		(mnémonique) Soutien Munitions
SP	SEA		(mnémonique) Soutien Pétrolier
SS	SSA		(mnémonique) Soutien Santé
SR	DRM
SD	DIRISI
SF	DAF
PFSO	PFAF_SO	EMA/SCA	Plate-forme achats-finances Sud-Ouest
PFNE	PFAF_NE	EMA/SCA	Plate-forme achats-finances Nord-Est
PFCE	PFAF_CE	EMA/SCA	Plate-forme achats-finances Centre-Est
PFIF	PFAF_IF	EMA/SCA	Plate-forme achats-finances Ile-de-France (IF pour IdF)
PFSE	PFAF_SE	EMA/SCA	Plate-forme achats-finances Sud-Est
PFOW	PFAF_OW	EMA/SCA	Plate-forme achats-finances Ouest (West)
PFCO	PFAF_CO	EMA/SCA	Plate-forme achats-finances Centre-Ouest
SPAC	SPAC
W	Washington
00	Non différencié		SE non différencié
Sxx	autres, à déf.		Autre SE (xx) à préciser

2 Structure, indicative, spécifique du SID.

NIV.	RADICAL DU CODE D'éOTP (PARTIE SE).	NB C.	DÉSIGNATION.	NB C.	REMARQUES.
n -1		0	actif-Infra	12	point d'accrochage
n	-CSXXXXXX-XXX	13	actif-localisation_xxxxx	24	Structure du SID
n +1	-CSXXXXXX-XXX-Yi	16	actif_Real-SE DDD-Immobilisé	16	Ligne réservée pour les "immobilisés" (IE), "type d'imputation" Y.
n +1	-CSXXXXXX-XXX-Vi	16	actif_Real-SE DDD-23193_Infrast Rout et Autr	32	Ligne réservée pour autre IA (ou V)/Le début (23) est retiré puisque commun.
n +1	-CSXXXXXX-XXX-Zi	17	actif_Real_SE DDD-charges (cas général)	35	Le caractère de charges est rappelé par le "type d'imputation" conventionnel Z.
n +1	-CSXXXXXX-XXX-ZPi	17	actif_Real_SE DDD-prestations	32	Ligne réservée pour les charges (type d'imput Z) à caractère de prestations.
n +1	-CSXXXXXX-XXX-ZCi	17	actif_Real_SE DDD-autres charges	35	Le caractère de charges est rappelé par le "type d'imputation" conventionnel Z.
n +1	-CSXXXXXX-XXX-Wi	17	actif_Real_SE DDDI-achats stockés par GM	35	Le caractère d'achat stocké par GM/par Article est rappelé par le "type d'imputation" conventionnel « W »/respectivement « S ».
n +1	-CSXXXXXX-XXX-Si	17	actif_Real_SE DDDI-achats stockés par Article	35

Les deux premières lettres : CS indique un code COSI, PL indique un code PLIMAT.

Le code COSI (CS) est composé d'un code identifiant de l'opération (dans le PEAE) et d'un code « affaire ».

En cas de besoin (limite du nombre de caractères), ces codes sont réduits sur accord commun du SID et de la DAF.

L'indice (i) est optionnel ; il est employé en cas de besoin de différenciation d'éOTP du même type d'imputation (même lettre finale).

3 Exemple de structure complète.

(Sous réserve de confirmation DGA pour la branche la concernant).

4 Modèles réguliers de branches d'« Utilisation ».

Les branches « Utilisation » des équipements militaires sont structurées selon le milieu concerné, des cas dérogatoires peuvent exister (rédaction/format non stabilisé).

Les éOTP de coût « historiques » ne sont pas indiqués.

Modèle pour les matériels terrestres.

La branche « Utilisation » distingue :

grandes visites ⁽¹⁾ (GV), éventuellement structurées par tranche annuelle ;
entretien courant (EC), structuré selon le service exécutant (SE) concerné (DGA ou SIMMT ⁽²⁾) ;
opérations majeures de rénovation/évolution, structurées par opération ;
exploitation ;
recettes.

Le schéma de ce modèle de branche est le suivant. Il peut être différencié par domaine fonctionnel (DF), non illustré ici sauf code xx entre l'armée détentrice et le service exécutant (exemple : entre « D-Axxx-U-L- » et « SE SIMMT» : D-Axxx-U-L-xxST-…).

Modèle pour les matériels navals.

La branche « Utilisation » distingue :

grandes visites ⁽³⁾ GV, structurées par grande visite ;
Soutien/entretien courant, structuré selon le service exécutant concerné (DGA ou SSF ⁽⁴⁾) ;
actions opérations majeures de rénovation/amélioration, structurées par opération ;
Exploitation/service ;
recettes.

Le schéma de ce modèle de branche est le suivant :

Modèle pour les matériels aéronautiques.

La branche « Utilisation » distingue :

soutien étatique, structuré par tranche annuelle et par aéronef pour les dépenses ;
soutien non étatique distinguant grandes visites, actions/opérations majeures de rénovation/amélioration ;
soutien en coopération ;
soutien par SE DGA ;
exploitation/service ;
recettes.

Le schéma de ce modèle de branche est le suivant :

5 Modèle standard, indicatif, pour les projets d'infrastructure.

Remarques :

Codification des éOTP : les codes des éOTP incorporent les n° PLIMAT ou COSI. (ex: D-Annn-I-PL-ppppppp-).

Les noms des phases et stades sont ceux de l'instruction de référence.

6 Modèle indicatif pour les projets de SIAG (Systèmes d'information d'Administration et de Gestion).

7 Modèle pour les études amont.

Annexe VI. Glossaire.

1. « Centre de profit ».

Le CdP est le « service à l'origine de la recette ».

Il est le responsable des objectifs budgétaires et de résultats en matière de coûts et de produits sur le périmètre des éOTP.

Il est aussi le responsable des centres de coût qui lui sont affectés.

Le découpage des CdP correspond à celui des grands responsables du ministère (Armées, Direction et grands Services).

Les consommations de ressources et les dépenses sont effectuées pour lui ou sa mission.

Il est responsable des objectifs en termes de produits générés par les activités de son ressort (recettes non fiscales, facturation interne). Au MINDEF le responsable du centre de profit est également responsable de programmes LOLF (RPROG) ou des BOP finançant les dépenses imputées directement sur les éOTP de son périmètre.

En conséquence, l'organisme « financeur » via son rôle de RCP (Responsable de centre de Profit ) (ex : GCPEMM0000) a la vue d'une part sur la destination et l'usage de ses crédits, d'autre part sur le niveau et l'origine des recettes non fiscales qui lui sont affectées.

Dans les éOTP, le CdP est identifié via le paramètre « centre de profit » sous un code de GCP (Gestionnaire de Centre de Profit ), ex : GCPEMM0000.

2. Centre financier.

Le Centre financier est l'organisme « détenteur » des crédits, que ceux-ci proviennent du budget général (BG) ou des recettes non fiscales (RNF).

Il fait partie de la chaîne financière RPROG, RBOP, RUO.

Il est responsable de la programmation budgétaire des dépenses et des recettes ainsi que des objectifs de performance sur le périmètre qui lui est confié.

En conséquence, l'organisme « détenteur» des crédits, via son code de CF, a la vue sur la consommation de ses crédits en termes de destination et d'usage.

Dans les éOTP, le CF est identifié via le paramètre « Centre Financier» sous un code alphanumérique gigogne de CF (PROG-BOP-UO),

Exemples :

BOP : DRM, 0178-0067 ;
UO : DRM, 0178-0067-DR02.

3. Centres de coûts.

CHORUS utilise deux types différents de CdCt :

les Services Bénéficiaire (SB) ;
les Service Gestionnaire de Bien (SGB).

3.1. Centre de coûts « service bénéficiaire ».

Le SB, en principe, est celui « pour lequel on dépense », équivalent à « celui qui coûte ».

Il représente une entité chargée :

soit d'acquérir le « bien » ou service à l'origine de la dépense, pour son propre compte, pour le compte d'un autre service ou pour le compte d'un projet,
soit de fournir un moyen (humain, actifs à utiliser, financier) à d'autres services ou aux projets.

Il n'identifie pas toujours le client final.

Il relève d'un seul centre de profit.

Le SB a un responsable identifié.

Il peut programmer des dépenses ou des consommations de ressources sur son périmètre.

Le SB ne porte que des dépenses, il ne porte pas de produits.

Sa codification intègre le code CREDO de cette entité (lien avec les SI RH).

C'est une information pour les lignes de gestion (LG) des EJ. Il ne doit pas être utilisé dans les éOTP.

L'entité agissant comme SB est indiqué sur la ligne de gestion LG de l'EJ (sous son code de SB).

En conséquence, l'organisme « coûtant » SB n'a pas de lien direct avec les éOTP.

Dans les éOTP, le SB n'est pas identifié via un paramètre (ce n'est pas l'objet de PS).

3.2. Centre de coûts « Service Gestionnaire de Bien ».

Le SGB est le responsable des immobilisations en cours ou en service, de son périmètre, au sens de la comptabilité générale (inventaire comptable, valorisation, déversements, etc.).

Le SGB a un responsable identifié : le RCAIM.

Il est utilisé sur les fiches d'immobilisations (FIEC, FIES) et les éOTP.

Il ne doit pas être utilisé dans les lignes de gestion (LG) des EJ.

Les SGB ne portent pas de dépenses mais uniquement les charges d'amortissements des actifs qui leur sont affectés.

En conséquence, l'organisme « responsable de la valorisation » des biens a la vue sur les montants collectés sur l'éOTP dans l'optique de leur prise en compte pour valoriser les immobilisations.

Dans les éOTP, le SGB est identifié via le paramètre « centre de coût responsable » CCR (accompagné du « périmètre analytique » BG00), sous son code de SGB, ex : SGBSCGC000.

4. « Centre de coût responsable ».

Le CCR est la désignation sous PS du SGB (voir SGB).

Dans les éOTP, le SGB est identifié dans le paramètre « centre responsable » sous son code de SGB, ex : SGBSCGC000.

Pour la gestion et le contrôle des éOTP, le responsable de la tenue de l'éOTP (paramétrage, création, modification, suppression éventuelle, etc.) est le RPROG dont dépend le RCAIM, identifié par son code de service gestionnaire de bien (SGB), positionné dans le paramètre PS « Centre de coûts responsable » (CCR) de l'éOTP. La « bonne tenue » des éOTP concerne le paramétrage, la tenue à jour incluse, des éOTP ainsi que les opérations associées, sans la possibilité de création d'éOTP -sauf déjà validée- ou de modification des codes.

5. « Service Exécutant ».

Le SE est « celui qui exécute la dépense » au profit d'un centre financier.

Le SE est une donnée de suivi des EJ. Il apparaît en « en-tête » des EJ.

6. « Responsable de la Comptabilité Auxiliaire des Immobilisations Ministériel ».

Dans PS ou les éOTP, le RCAIM est assimilé au SGB (voir SGB).

Dans les éOTP, le RCAIM est parfois identifié dans le paramètre « centre responsable » (noté CCR), quand il correspond au SGB avec alors un code de SGB, ex : SGBSCGC000.

En fait, le RCAIM (Responsable de la Comptabilité Auxiliaire des Immobilisations Ministériel) est le nouveau nom du RCAI (Responsable de la Comptabilité Auxiliaire des Immobilisations) mais c'est fonctionnellement la même chose.

En fait la distinction vient d'une exigence de DGFIP/France Domaine datant de 2012, qui a voulu :

que le terme RCAI (sans M) soit réservé aux « garants » du référentiel immobilier, c'est-à-dire à des agents de France Domaine ou en tout cas à des comptables du domaine (FIES Immobilières en sociétés régionales) ;
que le terme RCAIM soit réservé aux responsables des FIEC, et aussi à ceux des FIES hors immobilier.