CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

DELEGATION A LA SECURITE ROUTIERE

DÉPARTEMENT DU CONTRÔLE AUTOMATISÉ
--------------
DIRECTION DU NUMERIQUE
SOUS-DIRECTION DES SYSTEMES D’INFORMATION

CAHIER DES CLAUSES TECHNIQUES PARTICULIERES

(CCTP)

Accord-cadre relatif à la conception, au développement et à la

maintenance du système d'information des outils numériques du
département du contrôle automatisé du ministère de l’intérieur ainsi
qu’à la fourniture de prestations complémentaires associées

Le présent CCTP comporte les annexes suivantes :

Annexe 1 Découpage des prestations et des livrables Ŕ DPL

Annexe 2 CCT du ministère de l’intérieur

Annexe 3 Présentation du SI des outils du contrôle automatisé

Annexe 4 PSSI du MI

Annexe 5 PSSI des outils du DCA (Ex SIDCA)

Annexe 6 PSSI de l’ANTAI

Annexe 7 Présentation des IHM du SI

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 1 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Table des matières

I. CONTEXTE ET ENJEUX DU MARCHE ......................................................................................... 9
II. OBJET DU MARCHÉ .................................................................................................................... 10
III. ENVIRONNEMENT DU MARCHE ................................................................................................ 10
3.1 Présentation des acteurs du projet SI ..................................................................................... 10
3.2 Présentation du Département du Contrôle Automatisé (DCA) - maîtrise d’ouvrage du SI ..... 10
3.3 Présentation des assistances à maîtrise d’ouvrage ............................................................... 12
3.4 Présentation de la DNUM (maîtrise d’œuvre du SI) ............................................................... 12
3.5 Présentation des partenaires .................................................................................................. 13
3.6 Les utilisateurs du SI des outils numériques du contrôle automatisé ..................................... 13
3.7 Présentation des outils numériques du contrôle automatisé .................................................. 14
3.7.1 Origine du projet ........................................................................................................................14
3.7.2 Le système d’Information des outils numériques du contrôle automatisé ...............................15
3.7.3 Historique déploiement, hébergement, homologation .............................................................17
3.7.4 Les futurs potentiels outils numériques du contrôle automatisé ..............................................17
IV. DESCRIPTION TECHNIQUE DU SYSTEME EXISTANT............................................................. 18
4.1 État d’avancement des outils composants le SI ..................................................................... 18
4.2 Les outils en TMA ................................................................................................................... 18
4.2.1 Les outils métiers ........................................................................................................................18
4.2.2 La plateforme de maitrise et valorisation de la donnée (PMVD) ...............................................21
4.3 Les outils non mis en TMA ...................................................................................................... 22
4.4 Outillage et socle d’ingénierie ................................................................................................. 23
4.5 Les plateformes pour les outils du système d’information ...................................................... 25
4.5.1 Les environnements dans le cloud pi .........................................................................................26
V. DÉCOUPAGE DES PRESTATIONS ............................................................................................. 30
VI. GOUVERNANCE........................................................................................................................... 31
6.1 Gouvernance du SI global ...................................................................................................... 31
6.2 Gouvernance contractuelle ..................................................................................................... 32
6.3 Gouvernance des projets ........................................................................................................ 33
VII. DÉMARCHE DE CONCEPTION, DÉVELOPPEMENT ................................................................. 33
7.1 Principes de la démarche........................................................................................................ 33
7.2 Rôle des acteurs ..................................................................................................................... 34
7.3 Étape de conception technique et de développement agile ................................................... 36
7.3.1 Les cérémonies agiles .................................................................................................................37
7.3.2 Vélocité .......................................................................................................................................37
7.4 Étape de conception et de développement en cycle en V ...................................................... 38
7.5 Étape d’intégration sur la plateforme de l’administration ........................................................ 38
7.6 Étape de vérification (VA, VSR) .............................................................................................. 38

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 2 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

VIII. EXIGENCES .................................................................................................................................. 40

8.1 Exigences générales ............................................................................................................... 40
8.2 Exigences sur la documentation ............................................................................................. 40
8.3 Exigences sur la conduite des prestations.............................................................................. 42
8.4 Exigences sur la gouvernance ................................................................................................ 43
8.5 Exigences sur les ressources du titulaire................................................................................ 44
8.6 Exigences sur les moyens techniques et sur la cohérence de l’architecture technique globale
du système d’informations ................................................................................................................. 45
8.7 Exigences sur les vérifications et contrôle qualité .................................................................. 46
8.8 Exigences SSI ......................................................................................................................... 46
8.9 Délais de traitement des anomalies applicatives .................................................................... 47
IX. INDICATEURS ET MESURE DE LA QUALITÉ DE SERVICE ..................................................... 48
X. DISPOSITIONS COMMUNES À L’ENSEMBLE DES PRESTATIONS ......................................... 48
10.1 Lieux d’exécution et télétravail ................................................................................................ 48
10.2 Horaires d’exécution ............................................................................................................... 49
10.3 Habilitation et enquêtes d’accès ............................................................................................. 49
10.4 Dossier de pilotage, tableaux de bord et indicateurs .............................................................. 49
10.5 ÉQUIPE DU TITULAIRE ......................................................................................................... 50
10.5.1 Généralité ...................................................................................................................................50
10.5.2 règles de séniorité ......................................................................................................................50
10.5.3 niveaux de séniorité imposés .....................................................................................................50
10.6 Livrables .................................................................................................................................. 52
10.6.1 Généralité ...................................................................................................................................52
10.6.2 Norme de la documentation ......................................................................................................52
10.6.3 Exigences générales ....................................................................................................................52
10.7 Modalités de vérification des prestations ................................................................................ 53
10.8 Modalités de commande des prestations ............................................................................... 53
XI. PRESTATION 1 (P1) : INITIALISATION ET PRISE DE CONNAISSANCE .................................. 54
XII. PRESTATION 2 (P2) : CONCEPTION ET DEVELOPPEMENT DE PROJETS ........................... 56
XIII. PRESTATION 3 (P3) : assistance à la maîtrise et A la valorisation de données -PMVD ............ 64
XIV. PRESTATION 4 (P4) : TIERCE MAINTENANCE APPLICATIVE ................................................. 66
14.1 SP4.1 MAINTENANCE ADAPTIVE ET EVOLUTIVE ............................................................. 66
14.2 SP4.2 MAINTENANCE CORRECTIVE .................................................................................. 68
XV. PRESTATION 5 (P5) : EXPERTISE TECHNIQUE ET EN ARCHITECTURE .............................. 70
XVI. PRESTATION 6 (P6) : MISE EN PLACE ET MAINTIEN EN CONDITION OPERATIONNELLE DE
L’USINE LOGICIELLE Ŕ GESTION ET HEBERGEMENT DE L’OUTILLAGE DU SI ........................... 72
XVII. PRESTATION 7 (P7) : REVERSIBILITÉ ET TRANSFERT DES ACQUIS ................................... 75
XVIII. ANNEXE 1 Ŕ DECOUPAGE DES PRESTATIONS ET DES LIVRABLES ............................. 76
XIX. ANNEXE 2 Ŕ CCT DU MINISTERE DE L’INTERIEUR ................................................................. 76

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 3 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XX. ANNEXE 3 Ŕ PRESENTATION DU SI DES OUTILS DU contrôle AUTOMATISE ....................... 76

XXI. ANNEXE 4 Ŕ PSSI DU MINISTERE DE L’INTERIEUR ................................................................ 76
XXII.ANNEXE 5 Ŕ PSSI DES OUTILS DU DCA (EX SIDCA) ............................................................... 76
XXIII. ANNEXE 6 Ŕ PSSI DE L’ANTAI .............................................................................................. 76
XXIV. ANNEXE 7 Ŕ PRESENTATION DES IHM DU SI ................................................................... 76

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 4 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Liste des figures

Figure 1 : Les outils en production ........................................................................................................ 15
Figure 2 : Présentation générale de la plateforme ................................................................................ 26
Figure 3 : Architecture du tenant technique principal ............................................................................ 27
Figure 4 : Architecture des tenants techniques secondaires ................................................................ 27
Figure 5 : Architecture des tenants non techniques .............................................................................. 28
Figure 6 : Les environnements mis en place dans le cadre du projet SIDCA ....................................... 29
Figure 7 : Synthèse de la gouvernance ................................................................................................. 31
Figure 8 : Rôle des acteurs dans le cadre d'une démarche Agile ......................................................... 35
Figure 9 : Synthèse de la démarche de conception et développement en mode Agile ........................ 36
Figure 10 : Organisation des cérémonies Agile .................................................................................... 37

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 5 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

GLOSSAIRE

ANTAI Agence Nationale du Traitement Automatisé des Infractions

AMOA Assistance à Maîtrise d’Ouvrage

AMOE Assistance à Maîtrise d’Œuvre

ANSSI Agence Nationale de la Sécurité des Systèmes d’Information

Backlog Ensemble des besoins recueillis et priorisés par le PO pour créer le produit cible
désiré.

CA Contrôle automatisé

CCAP Cahier des clauses administratives particulières

CCTP Cahier des clauses techniques particulières

CNIL Commission Nationale de l’Informatique et des Libertés

CNT Centre National de Traitement des amendes basé à Rennes

DCA Département du Contrôle Automatisé

DCE Dossier de consultation des entreprises

DNUM Direction du Numérique

Programme Dispositif d’EXTERnalisation de la conduite des véhicules de radars

DEXTER
mobiles

DSR Délégation à la Sécurité Routière

ET : Équipements de terrain radars de type :

ETC Chantier (ou Autonome ou Transitoire)
ETD Discriminant VL, PL
ETD2F Discriminant double face
ETED Embarqué Débarquable
ETF Fixe
ETM Mobile
ETS Signalisation (Panneaux SR3)
ETVM Vitesse Moyenne (Ou tronçon)
ETPN Passage à niveau
ETFR Franchissement ou Feu Rouge
ETT Tourelle
ETU Urbain

GMAO Gestion de la maintenance assistée par ordinateur

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 6 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

GPRS General Packet Radio Service

GPS Global Positioning System (ou système de géolocalisation par Satellite)

GS Glissière de Sécurité

IGC Infrastructure de Gestion de Clés

IHM Interface Homme Machine

MCO Maintien en condition opérationnelle

MCS Maintien en condition de sécurité

MI Ministère de l’intérieur

MOA Maître d’ouvrage

PAQ Plan d’assurance qualité

PAQS Plan d’assurance qualité sécurité

PDL Point de livraison

PMVD Plateforme de Maîtrise et de Valorisation de la Donnée

PMP Plan de Management Projet

Programme Cette notion englobe la TMA et les projets de développement d’outils

Ensemble de développements nécessitant l’affectation d’une équipe dédiée, soit pour

Projet
des fonctionnalités majeures d’un outil existant, soit pour un nouvel outil

PSSI Politique de Sécurité des Systèmes d’Information

POKER Mode d’estimation de l’effort de développement d’une fonctionnalité selon la méthode

PLANNING Agile SCRUM.

PV Procès-verbal
Une release est une nouvelle version du produit, livrée aux utilisateurs et destinée à
Release
être mise en production. Elle est le résultat de plusieurs sprints.
SI Système d’Information

SIG Système d’Information Géographique

SIGDCA Anciens noms des projets de développement des outils numériques du CA qui restent
cependant dans la documentation et dans le paramétrage des outils.
SISDCA
SIG pour la partie géographique
SIDCA
SIS pour la partie soutien
SIDCA était la fusion des deux.

SIDCA Système d’Informations du Département du Contrôle Automatisé.

Nom du projet ayant permis la mise en place des premiers outils du contrôle
automatisé.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 7 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

SSI Sécurité des Systèmes d’Information

TMA Tierce Maintenance Applicative

User story (US) Une user story est une phrase simple, exprimée dans un langage commun et
permettant de décrire avec suffisamment de précision le contenu d'une fonctionnalité à
développer. La phrase contient généralement trois éléments descriptifs de la
fonctionnalité : Qui ? Quoi ? Pourquoi ? Elle peut être formalisée comme suit :
« En tant que <qui>, je veux <quoi> afin de <pourquoi> ».
Une user story traduit le point de vue métier.

VA Vérification d’aptitude

VSR Vérification de service régulier

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 8 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

I. CONTEXTE ET ENJEUX DU MARCHE

Les mesures du comité interministériel de la sécurité routière (CISR) de 2015 ont conduit la délégation
à la sécurité routière (DSR) à devoir développer des outils spécifiques complémentaires aux outils
historiques de maintenance du parc « radar » pour gérer de nouvelles activités. Ces outils permettent
en particulier d’accompagner l’externalisation de la conduite des radars mobiles à des prestataires de
conduite, le déploiement de panneaux pour constituer des itinéraires de contrôle renforcés, la
maintenance des panneaux associée, l’interface entre les gestions de la maintenance assistée par
ordinateur (GMAO) des acteurs, etc.
Ces outils sont développés dans l’objectif de faciliter la coordination et le suivi des opérations de
déploiement et de maintenance rendus complexes du fait de la répartition sur l’ensemble du territoire
français et du nombre d’interlocuteurs.
Les utilisateurs de ces outils sont les correspondants sécurité routière des préfectures
départementales et des directions Départementales des Territoires (DDT) de métropole et des
départements et régions d’Outre-mer (DROM), la DSR au travers du département du contrôle
automatisé (DCA) et les industriels privés titulaires des marchés qui réalisent la fourniture, le
déploiement, l’exploitation et la maintenance des équipements sur le terrain.
Les outils de représentation cartographique des données sont privilégiés pour les interfaces avec les
préfectures et les DDT. Les outils utilisés entre le DCA et ses titulaires sont développés si leur coût de
développement et de maintenance est compensé par des gains de productivité et de qualité
opérationnelle pour le DCA.
D’autre part, la maitrise de l’efficacité du contrôle automatisé par rapport aux objectifs de sécurité
routière nécessite une analyse permanente des activités de déploiement, de maintenance, de
production et d’exploitation. Pour faciliter ces analyses, souvent récurrentes, une plateforme DATA de
type datalake, appelée « plateforme de maîtrise et de valorisation de la donnée » (PMVD), a été mise
en place pour industrialiser ces reportings et permettre des analyses fines.
L’accord-cadre de développement des premiers outils arrivant à terme, le présent accord-cadre a pour
objet la maintenance des outils actuellement en exploitation et le développement des nouveaux outils
dont a besoin la DSR.
Les principales évolutions par rapport à l’accord-cadre précédent, sont les suivantes :
- une responsabilité accrue du titulaire sur les délais de livraisons, la qualité et les coûts d’un
outil ou d’une fonctionnalité complète. Pour cela, il réalise la partie conception, les
spécifications techniques détaillées et la documentation fonctionnelle des outils qui ne sont
pas dans le périmètre de l’actuel marché ;
- la capacité de réaliser les développements soit en mode AGILE soit de manière plus
classique en cycle en V sur les applications existantes ou pour des nouvelles. Le choix sera
réalisé au cas par cas en fonction des outils, de la maturité des spécifications fournies par le
DCA et de la disponibilité du DCA.
Pour la partie hébergement et architecture, et à la différence des outils historiques, les applications
n’ont pas été hébergées au centre national de traitement (CNT) de l’agence nationale de traitement
automatisé des infractions (ANTAI) mais dans le cloud PI de la DNUM. Le projet a été précurseur de
l’utilisation du cloud PI et a construit ses propres services de déploiement et un outillage et des
environnements complets et propres au projet. La partie en production est également sécurisée par un
PRI/PCI sur un site cloud de secours de la DNUM. La livraison dans le cloud est actuellement réalisée
par des images dans un environnement d’intégration et la forge ne permet pas de déployer à partir
des codes sources. Cette situation n’est pas satisfaisante.
Les applications ont des interfaces avec des systèmes d’information externes (IGN, SI ANTAI, SI
titulaires de marché) et une interface spécifique, mise en place pour le projet, avec certains types
d’équipements de terrain via une infrastructure télécom propre à la DSR.
La DSR souhaite que le socle technique d’hébergement et les choix techniques réalisés
(environnement) soient adaptés aux besoins de la DSR en termes de services et optimisés en termes
de coût.
Il est demandé au titulaire d’assister la DNUM et la DSR dans la réalisation de cet objectif, en
apportant d’une part l’expertise et le conseil sur les choix techniques et temporel des évolutions et

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 9 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

d’autre part de réaliser les spécifications et le suivi des évolutions de l’architecture qui pourront être
mises en œuvre par les équipes de construction, exploitation et d’intégration.

II. OBJET DU MARCHÉ

Le présent accord-cadre (dans la suite du document, les termes « accord-cadre » et « marché » sont
synonymes) a pour objet la conception, le développement, la maintenance (corrective, évolutive,
adaptative) du système d'information des outils numériques du département du contrôle automatisé
du ministère de l’intérieur (également intitulé par la suite « SI ») ainsi que la fourniture de prestations
complémentaires.

III. ENVIRONNEMENT DU MARCHE

3.1 PRESENTATION DES ACTEURS DU PROJET SI
Les principales parties prenantes du SI des outils numériques du contrôle automatisé sont :
 le DCA qui assure la maîtrise d’ouvrage (MOA) du SI ;
 une assistance à maîtrise d’ouvrage SI (AMOA SI) du DCA confiée à un prestataire externe ;
 la DNUM qui assure la maîtrise d’œuvre du SI ;
 une assistance à maîtrise d’œuvre de la DNUM sur l’intégration, l’installation et l’exploitation
du SI confiée à un prestataire externe sous le pilotage du bureau d’intégration et d’exploitation
(BIE) de la DNUM ;
 l’assistance à maîtrise d’œuvre, objet du présent marché, relative à la conception, au
développement, à la tierce maintenance applicative (TMA) et au maintien en condition
opérationnelle (MCO) du SI, elle sera dénommée AMOE SI/ARCHI ;
 des partenaires, dont les systèmes d’information sont interfacés avec les outils numériques du
contrôle automatisé ;
 les bénéficiaires des outils numériques du contrôle automatisés.
Sauf exception, le DCA et son AMOA sont désignés dans le présent document sous le terme
générique « le DCA ».
Le titulaire collabore étroitement, dans le cadre de ce projet, avec la DNUM et le DCA et ses AMOA
qui sont, sauf exception, désignés dans le présent document sous le terme générique « le DCA ».
3.2 PRESENTATION DU DEPARTEMENT DU CONTROLE AUTOMATISE (DCA) - MAITRISE D’OUVRAGE DU SI
Dans le cadre de sa politique de sécurité routière, le gouvernement a mis en place dès 2002 un
système de contrôle automatisé des infractions au code de la route, portant sur le contrôle de la
vitesse (instantanée et moyenne) et le contrôle du respect des signalisations lumineuses (feux de
signalisation et passages à niveau).
Ce système répond à un triple objectif :
 améliorer la sécurité sur la route en suscitant une modification profonde des comportements
routiers et en faisant baisser la délinquance routière ;
 rapprocher la sanction de la commission de l’infraction ;
 affecter les forces de l’ordre à d’autres missions.
Les progrès réalisés en matière de sécurité routière depuis 2002 sont en grande partie imputables à la
politique de contrôle automatisé ainsi mise en place.
La mise en œuvre de la politique de contrôle automatisé définie par le gouvernement au travers du
CISR est assurée par deux structures placées sous l’autorité du ministère de l’intérieur :
 le département du contrôle automatisé (DCA), chargé du déploiement et de la maintenance
des équipements de contrôle automatisé appelés communément « radars automatiques ». Le
DCA est rattaché à la DSR, qui élabore et met en œuvre la politique de sécurité routière et
apporte son concours à l’action interministérielle dans ce domaine ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 10 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 l’ANTAI chargée notamment du traitement des infractions issues des radars automatiques,
par l’intermédiaire du CNT basé à Rennes.
Le DCA prépare la stratégie en matière de contrôle automatisé et assure le pilotage de sa mise en
œuvre.
A ce titre, il :
 met à disposition des services territoriaux de l'État les outils qui leur permettent de mettre en
œuvre la politique locale du contrôle automatisé ;
 élabore la réglementation relative aux équipements de constatation des infractions au code de
la route telle que définie au 4°de l'article R. 111-1 du code de la voirie routière ;
 pilote le déploiement, le déplacement, l'évolution et la maintenance des équipements de
contrôle et s'assure de l'organisation logistique générale afin de permettre aux services locaux
de l'État de décliner la stratégie du contrôle automatisé ;
 assure la préparation et le suivi financier des marchés publics nécessaires à la mise en œuvre
du contrôle automatisé. Il assure le suivi des contentieux dans ce domaine ;
 pilote l'évolution technique du contrôle automatisé, l'amélioration des équipements déployés
sur le terrain, la numérisation des processus, ou l'outillage statistique permettant d'optimiser
l'efficacité des contrôles.
Le DCA assure la MOA du système d'information des outils numériques du contrôle automatisé, via
deux pôles et un bureau :
 un pôle « innovation » (MOA-SI), qui pilote l'évolution technique du contrôle automatisé,
l'amélioration des équipements déployés sur le terrain, la numérisation des processus, et
l'outillage statistique permettant d'optimiser l'efficacité des contrôles ;
 un bureau chargé des moyens opérationnels (MOA métier), qui met à disposition des services
territoriaux de l'État les outils qui leur permettent de mettre en œuvre la politique locale du
contrôle automatisé, pilote le déploiement, le déplacement, l'évolution et la maintenance des
équipements de contrôle et s'assure de l'organisation logistique générale afin de permettre
aux services locaux de l'État de décliner la stratégie du contrôle automatisé ;
 un pôle « soutien » (MOA métier), en charge de la préparation des marchés publics
nécessaires à la mise en œuvre du contrôle automatisé et effectue leur suivi financier.
Le DCA est le donneur d’ordre au profit du produit réalisé, il est le « maître métier » de son projet. Elle
dispose d’une vision globale de son projet et de toutes les facettes métiers tant sur les aspects
organisationnels que fonctionnels :
 il exprime la finalité de son projet dans un contexte « métier » ;
 il spécifie son besoin « métier » ;
 il exprime ses besoins en matière de sécurité (niveau de confidentialité, disponibilité, etc.) ;
 il fixe les objectifs fonctionnels, de coûts et de délais de projet ;
 il choisit le scénario de mise en œuvre sur la base des préconisations de la DNUM (MOE) ;
 il participe aux comités de décisions qui fixent les grandes orientations du projet à chacun des
jalons de la procédure projet ;
 il participe aux travaux de réception du projet.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 11 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

3.3 PRESENTATION DES ASSISTANCES A MAITRISE D’OUVRAGE

Le DCA est assisté par une AMOA « SI », qui intervient sur les activités suivantes :
 l’assistance à la définition des besoins métiers (constitution et mise à jour du backlog produit),
aux recettes, à la mise en service et au pilotage du projet ;
 l’administration fonctionnelle des outils numériques du contrôle automatisé, le traitement de
données, l’assistance aux utilisateurs, la gestion des anomalies et la conduite du
changement ;
 l’assistance sur le volet « sécurité » du SI : élaboration de la politique de sécurité des
systèmes d’information (PSSI), analyse de risques EBIOS, audit de sécurité des systèmes
d’information (SSI), maintien en condition de sécurité (MCS), etc. ;
 le conseil, l’expertise et l’assistance à la validation et à la vérification des documents produits
par le titulaire du présent marché (AMOE SI/Architecture) ;
 les recettes fonctionnelles des applications et modules applicatifs développés par le titulaire
du présent marché (AMOE SI/Architecture).
De plus, une AMOA « métier » est chargée d’assister le DCA dans la gestion opérationnelle des
activités.
Enfin, une AMOA « Nova » complète ce dispositif en accompagnant le DCA dans le développement
des nouveaux radars.
Comme indiqué plus haut, le DCA et ses AMOA sont désignés dans le présent document sous le
terme générique « le DCA », la gouvernance entre le DCA et ses AMOA vis-à-vis du titulaire sera
précisé au titulaire lors de la première phase du marché et pourra évoluer.
3.4 PRESENTATION DE LA DNUM (MAITRISE D’ŒUVRE DU SI)
La direction du numérique (DNUM) du ministère de l’intérieur élabore et conduit la stratégie numérique
du ministère. Dans le respect de leurs priorités opérationnelles, elle en assure la déclinaison et
contribue à l'unité, à la cohérence, à la qualité et à la sécurité des systèmes d'information et de
communication du ministère.
La DNUM comprend :
 le service de pilotage stratégique et gouvernance (SPG) comprenant la sous-direction de la
gouvernance (SDG) et la sous-direction des ressources (SDR) ;
 la sous-direction de l’innovation et la transformation numérique (SDITN) ;
 la sous-direction de la coordination des acteurs SIC et services transverses (SDCAST) ;
 la sous-direction de l’architecture et des infrastructures techniques (SDAIT) ;
 la sous-direction des systèmes d’information (SDSI) ;
 la mission politique SSI (MPSSI) ;
 la mission audit, qualité et évaluation (MAQE).
Elle chargée de la maîtrise d’œuvre (MOE) du SI et intervient à différents niveaux :
- le bureau des applications d'appui aux agents (B3A), rattaché à la SDSI, assure la maitrise
d’œuvre (MOE) du SI des outils numériques du contrôle automatisé et la coordination entre
les différentes entités de la DNUM. Il pilote le présent marché d’AMOE ;
- la mise en place des plateformes, sur le cloud de la DNUM (intitulé cloud PI) via le bureau de
l’architecture et de la cohérence des infrastructures ;
- l’intégration et l’exploitation du SI des outils numériques du contrôle automatisé et de la PMVD
par le BIE, appuyé par un prestataire externe ;
- la réalisation des tirs de performance définis par le projet, assurée par le bureau de la
performance et de la sécurité applicative (BPSA) de la SDSI ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 12 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

- le bureau de supervision de la SDAIT qui supervise les SI.

3.5 PRESENTATION DES PARTENAIRES
Le SI des outils numériques du CA s’interface avec d’autres SI ou services sur le long terme et à cette
fin, le DCA collabore avec des partenaires essentiels au bon fonctionnement du système
d’information. Il entretient une relation spécifique avec chacun d’entre eux au travers l’organisation de
comités spécifiques pour lesquels l’AMOE peut être sollicitée. En complément de ces comités, un
comité trajectoire réunit l’ensemble de ces partenaires afin de partager la feuille de route
(« roadmap ») du SI. Ces partenaires sont :
 l’ANTAI sous la tutelle de la DSR pour :
o des échanges d’informations entre les SI de l’ANTAI et le SI des outils numériques du
contrôle automatisé ;
o la collecte et exploitation des données sur les radars déployés en France ;
o la génération des certificats des radars ;
 l’observatoire national interministériel de sécurité routière (ONISR) qui fait partie de la DSR
pour :
o des échanges d’‘informations entre le SI Accident et le SI des outils numériques du
contrôle automatisé (données accidents, localisation contrôles,…) ;
o l’utilisation de la PMVD pour les besoins propres aux études des data-scientistes de
l’ONISR ;
 l’institut national de l'information géographique et forestière dans le cadre de conventions
avec la DSR pour :
o l’intégration des services cartographiques de l’IGN (couches géographiques affichées
dans les outils ;
o l’utilisation des bases de données cartographiques (réseau routier, etc.) et du RGE
(Référentiel à grande échelle) ;
o des services de géomatiques développés et hébergés spécifiquement pour la DSR
sous forme d’API (API itinéraire, géocodage inverse, nom route, etc.) ou
d’algorithmes.

3.6 LES UTILISATEURS DU SI DES OUTILS NUMERIQUES DU CONTROLE AUTOMATISE

Le tableau ci-après regroupe la liste des acteurs du SI et la volumétrie estimée :

Nombre indicatif
Acteur Périmètre
d’utilisateurs
Administration centrale, en charge de la politique de
DCA et assistances 70
déploiement des radars.
En charge du SI du contrôle automatisé et de la constatation
ANTAI / CACIR OMP 18
des infractions.
Administration déconcentrée, chargée de la politique locale de
Préfectures et la sécurité routière ;
services
Définition des besoins locaux en contrôles automatisés ;
départementaux 275
associés Direction départementale des territoires ;
(DDT/DDTM) Chefs de projet locaux pour l’ensemble des tâches à réaliser
pour l’implantation d’un radar (« AMOA » des préfectures).
Gestionnaires de Direction interdépartementale des routes ;
voirie hors 172 Gestionnaire de voirie.
communes Conseils départementaux.
Forces de sécurité 100 Contribue à la définition des missions de contrôles mobiles.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 13 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Nombre indicatif
Acteur Périmètre
d’utilisateurs
intérieure
Titulaires de marchés DSR en charge :
 de la construction des équipements (radars,
panneaux) ;
 de liaison Télécom entre les radars et les systèmes
d’information ;
Prestataires du DCA
(hors DEXTER)
135  des opérations de travaux déploiement des radars,
panneaux et des emplacements de radars ;
 des opérations de maintenance et vie du parc sur les
radars, panneaux et les emplacements de radars ;
 des opérations de déplacement ou rotation des
dispositifs de contrôles entre des cabines « leurres ».
Prestataire de
l’exécution des
Titulaire de marchés DSR en charge de l’exécution des
contrôles 580
missions de contrôles (coordinateurs et conducteurs).
automatisés :
DEXTER
TOTAL 1 350

3.7 PRESENTATION DES OUTILS NUMERIQUES DU CONTROLE AUTOMATISE

3.7.1 ORIGINE DU PROJET

Le contrôle sanction automatisé est divisé en deux métiers :

 le métier du contrôle automatisé ;
 le métier de la caractérisation de l’infraction et de la gestion de la sanction. Ce deuxième
métier a été largement numérisé avec la création du CNT par l’ANTAI.
Le système d’informations des outils numériques du contrôle automatisé vient outiller le premier
métier.
Au cours des dernières années, le département du contrôle automatisé a réorienté l’ensemble de sa
stratégie de manière à permettre un changement de comportement des usagers de la route suffisant
pour atteindre l’objectif gouvernemental d’une baisse des accidents de manière à avoir moins de 2000
morts initialement en 2020 sur les routes françaises.
Cette stratégie, telle qu’elle a été validée par le Gouvernement lors du CISR du 2 octobre 2015,
repose sur les principales mesures suivantes :
 avec les itinéraires de contrôle par panneau leurre, prévenir le conducteur qu’il sera
régulièrement contrôlé sur les routes les plus préoccupantes (mesure 1) ;
 avec l’externalisation de la mise en œuvre des voitures radars (mesure 2), et l’augmentation
du nombre de radars autonomes (mesure 4), les contrôles pourront être massifiés sur ces
itinéraires ;
 une approche similaire sera organisée en agglomération avec les leurres par cabine (mesure
1) ;
 ce changement de comportement sera analysé de manière à avoir une boucle de rétroaction
qui permet de doser le bon niveau de densité de contrôle au niveau pour induire le
changement de comportement sur le périmètre le plus vaste possible, et qui permet de
réaliser les contrôles sur les zones les plus pertinentes ;
 les infractions contrôlées seront étendues à d’autres infractions de manière à lutter contre
l’ensemble des comportements qui augmentent le risque ou la gravité des accidents (mesure
3) ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 14 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 la base de données des vitesses limites autorisées permettra aux conducteurs de savoir en
permanence et sur tout le territoire la vitesse maximale autorisée, de manière à limiter l’impact
des contrôles sur les conducteurs de bonne foi, qui cherchent autant que possible à respecter
les limites de vitesse, mais qui ne la connaissent pas toujours (mesure 17).
Cette stratégie conduit à multiplier par 100 voire 10 000 les opérations de contrôle automatisé sur tout
le territoire français.
Ainsi, la multiplication des opérations, nécessitant par ailleurs la collaboration de dizaines d’acteurs, a
justifié la mise en place d’un système d’information (SI) spécifique permettant notamment :
 des échanges rapides d’informations rapides et la structuration des actions collaboratives
pour plus d’efficience dans un contexte de moyens humains et financiers limités ;
 l’optimisation de la mobilité accrue des radars grâce à la mise en œuvre d’un système de
localisation géographique, rendant aisée et intuitive la visualisation des positionnements et
mouvements opérés.
3.7.2 LE SYSTEME D’INFORMATION DES OUTILS NUMERIQUES DU CONTROLE AUTOMATISE

3.7.2.1 Cartographie fonctionnelle actuelle du SI des outils du CA

L’ensemble du SI est divisé en systèmes qui sont autant de briques applicatives faisant l’objet de
projets de développement et/ou maintien en conditions opérationnelle dans le cadre du présent
marché.
Les systèmes « métiers » sont repérés par une numération préfixée par la lettre « S ».
Les systèmes en production à date de rédaction du CCTP figurent dans le schéma ci-dessous :

Figure 1 : Les outils en production

Les outils numériques du contrôle automatisé permettent au DCA :

 d’interagir avec les administrations déconcentrées par le biais d’une approche géographique ;
 de réaliser le pilotage et le suivi du déploiement, de la maintenance et de l’exploitation des
dispositifs de contrôle automatisé par la numérisation partielle ou complète des processus en
fonction du gain ;
 de réaliser la boucle de rétroaction sur les actions de sécurité routière.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 15 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Une numérisation partielle correspond par exemple à un workflow où les données sont dans les
pièces jointes et ne sont donc pas exploitables directement en base.
Les outils en TMA
La construction des outils numériques du contrôle automatisé a été réalisée de façon progressive
depuis 2016 dans le cadre d’un premier projet appelé SIDCA, via la mise en production des briques
applicatives suivantes métier appelées aussi « systèmes » :
 S1 - un système de pilotage de la demande et la réalisation des itinéraires et emplacements
des radars autonomes, ainsi que de la demande de certains types de radars ;
 S2 - un système de pilotage des missions de contrôles par voiture mobiles ;
 S41 - un système de gestion des opérations de maintenance sur panneaux et d’affichage
cartographique de tous les ET associés à une fiche descriptive alimenté par les X-PILOTE de
l’ANTAI ;
 S10 : un système de supervision des échanges entre les GMAO des titulaires pour la gestion
des stocks du DCA et leurs approvisionnements ;
 ITEROP : un outil COTS de workflow utilisant des diagrammes, des formulaires et des
notifications permettant au métier de construire (designer) et mettre en exploitation des
processus de manière autonome ;
 PMVD : une plateforme de maitrise et de valorisation de la donnée, partagée avec l’ONISR
permettant de centraliser l’ensemble des données dans un datalake et de les exploiter pour
réaliser des indicateurs et des analyses.
Ces systèmes métiers sont accompagnés par les outils transverses suivants :
 SA Ŕ un système d’accès, appelé le portail, permet de gérer de manière commune les
utilisateurs (annuaire) et leurs postes, ainsi que le périmètre des organisations titulaires des
marchés (Réf. marché) ;
 SREF ET Ŕ un référentiel des équipements de terrain aujourd’hui alimenté par les X-PILOTE
de l’ANTAI ;
 S9 Ŕ des échanges multicanaux, outils de ticketing pour l’assistance des utilisateurs ;
 GED : un système de gestion électronique de documents pour le partage des livrables non
numérisés.
Ces systèmes sont complétés par des interfaces :
 Développées avec des SI partenaires :
o l’ONISR qui a développé le SI Traxy permettant de construire et analyser la base de
données des accidents ;
o l’ANTAI pour récupérer les données issues des deux SI historiques FR et VT PILOTE
(appelés aussi les X-PILOTE) qui centralisent encore les informations de maintenance de
tous les radars ;
o l’IGN qui fournit l’ensemble des couches géographiques ainsi que des API métier utilisées
par les outils ;
o le titulaire du marché des kits d’externalisation de la conduite ;
o MOBIOM, un des titulaires des marchés d’externalisation qui pour des raisons de
sensibilité a une partie de son application hébergée avec les outils du CA.
 Développées avec les équipements de terrain :
o certains radars pour la remontée d’information ;
o les tablettes de navigation des voitures qui embarquent un logiciel spécifiquement
développé pour faire le lien entre le système S2 front et les conducteurs.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 16 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

3.7.3 HISTORIQUE DEPLOIEMENT, HEBERGEMENT, HOMOLOGATION

Les deux premiers systèmes S1 et S2 ont été mis en production sur les plateformes ISOCELE de la
DNUM avant 2019.
Suite à la décision de se connecter directement aux équipements de terrain pour les futurs outils, il a
été décidé en 2018 d’héberger les outils dans ce qui était à l’époque le futur cloud PI du ministère.
Cette migration a été réalisée fin 2019 avec la migration des outils S1 et S2 dans un portail commun
et vers l’utilisation d’un système d’identification et de gestion des utilisateurs unique (SSO). Au cours
de cette étape a été également mis en production l’outil d’assistance utilisateur par ticketing.
Le SI est aujourd’hui homologué selon la démarche « standard » de la DISSIP EBIOS FEROS sur le
périmètre technique. Cette homologation a été confirmée à chaque changement de périmètre au fur et
à mesure de l’ajout d’applications. Lors de la rédaction du présent CCTP, l’homologation est sur le
périmètre cloud4 et devrait être au périmètre cloud 5 au début du présent marché.

3.7.4 LES FUTURS POTENTIELS OUTILS NUMERIQUES DU CONTROLE AUTOMATISE

A date de rédaction du présent CCTP, et compte tenu de l’état d’avancement du SI (voir § 4.1 « État
d’avancement des outils composants le SI »), l’ambition est désormais d’aborder la poursuite de la
construction des systèmes non plus d’une manière globale, mais dans une logique de construction, de
maintenance et d’évolutions par projet mis en cohérence par des référentiels et outils communs, mais
pouvant se déployer et se maintenir de manière indépendante.
Le planning de développement de nouveaux outils est décidé par le DCA, en fonction de ses priorités
projet et de sa capacité de pilotage. Ces développements sont réalisés en mode Agile ou en cycle en
V en fonction de la maturité du besoin et de la taille du projet. En cours de projet, le DCA peut décider
de re-prioriser les développements et le titulaire doit être en mesure de s’y adapter.
La collaboration avec le titulaire doit respecter les principes suivants :
 la conception des potentiels futurs outils doit être pilotée par une analyse préalable et
permanente portant sur le ROI de la numérisation de la fonction à long terme en termes
d’équivalent temps plein et d’apport de valeur ajouté aux acteurs de la sécurité routière ;
 l’évaluation de l’opportunité d’utiliser des outils sur étagère (COTS) doit être effectuée pour
limiter les coûts et bénéficier de développements déjà réalisés ;
 une conception simple, résiliente et robuste par rapport aux évolutions de doctrine métier et
des process du contrôle automatisé, aux changements de titulaires de marchés et de
périmètres de marchés, et tout autre aspect ;
 une conception permettant le droit à l’erreur et la correction par le métier ;
 une prise en compte dès le départ de l’exploitation de la donnée produite par les process pour
l’aide au pilotage opérationnel et à la réalisation de reportings globaux en lien avec la PMVD ;
 la maintenabilité du système par rapport à la qualité des développements et aux choix de
briques logicielles, framework réputés pérennes et maitrisables par la DNUM et/ou la
communauté informatique en général ;
 la prise en compte des différentes typologies d’utilisateurs.
Dans le cadre du présent marché un certain nombre de fonctionnalités ont été identifiées mais n’ont
pas fait l’objet d’arbitrage à ce stade, et pourront éventuellement être réalisées (liste non exhaustive) :
3.7.4.1 Exemples de potentiels futurs outils :

 Un guichet unique pour les préfectures/DDT leur permettant de réaliser une demande de
sécurisation d’une zone ponctuelle ou étendue et d’avoir un échange avec le DCA pour
déterminer la solution de contrôle retenue ;
 un guichet unique pour les préfectures/ DDT permettant de signaler un évènement sur leur
parc radar (dégradation, …) avec le suivi de l’intervention associée décidée par le DCA ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 17 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 un accès en ligne aux préfectures/DDT leur permettant d’avoir les informations sur leur parc
radar en cours de déploiement et en service ;
 la mise à disposition des préfectures et DDT de ressources cartographiques, de données,
d’outils de calculs sur ces éléments, utiles pour le pilotage de leur stratégie de contrôle pour la
sécurité routière ;
 la mise en place des référentiels emplacements radars, panneaux, marchés, DDT/DDTM
communs pour toutes les applications ;
 un outil commun pour le DCA et ses mainteneurs permettant le suivi des opérations de
maintenance (périodique, curatif, évolutif) de tous les types d’équipements du CA ;
 un outil partagé entre le DCA, les DDT/préfectures et les mainteneurs, d’expression de
besoin, de planification et de suivi des rotations pour le DCA et les DDT des dispositifs de
contrôles de type radar autonome ou de type Unité de Contrôle automatisé (UCA entre les
cabines ETT ou ETU ;
 un outil commun pour le DCA et les mainteneurs pour numériser la réalisation et le pilotage
des processus de validation du contenu des livrables lors des processus de déploiement ;
 un outil de constitution de la base de données des VMA de référence pour l’IGN.
3.7.4.2 Fonctionnalités liées à la refonte des outils historiques X-PILOTE

 Un outil de supervision pour le DCA et ses mainteneurs sur leur périmètre des alarmes
technique des ET, des alertes en provenance d’autres SI (les chaines de traitement de
l’ANTAI) et des signalements multi-canaux (cf. guichet unique ci-dessus) ;
 Un outil commun pour le DCA et les mainteneurs pour numériser la réalisation et le pilotage
des processus de déploiement pour tout type de radar.
IV. DESCRIPTION TECHNIQUE DU SYSTEME EXISTANT
4.1 ÉTAT D’AVANCEMENT DES OUTILS COMPOSANTS LE SI
Les paragraphes qui suivent donnent un état d’avancement de chaque outil à la date de publication du
marché permettant au candidat d’apprécier la complexité et les compétences nécessaires pour la
réalisation de la prestation.
4.2 LES OUTILS EN TMA
4.2.1 LES OUTILS METIERS

Les outils suivants sont soit déjà déployés en production et opérationnels et seront à maintenir,

Systèmes Objectifs métiers Socle État d’avancement

technologique

Outils métiers
Vertigo/Struts ;
S1 pilotage des Système de gestion des demandes Déployé et en
Open Layer
emplacements et des d'itinéraires panneau leurre et des production avec de
(cartographie) ;
itinéraires demandes d'emplacement ETC pour les nouvelles versions
Postgre SQL ;
sites isolés ou sites chantiers. Il inclue le régulières pour
pilotage des emplacements et des Geoserver intégrer des
itinéraires : suivi de l’instruction d’un (notifications). améliorations.
dossier d’implantation depuis son projet
jusqu’à la mise en place des panneaux et
des emplacements associés. Contient
aujourd’hui le référentiel des emplacements
ETC.
Il permet également aux DDT de réaliser
des demandes sur les ETT, cette

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 18 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

fonctionnalité provisoire pourrait évoluer en

guichet unique.
Vertigo/Struts ;
S2 front pilotage des Système de pilotage des voitures radars, Déployé à tous les
Open Layer ;
missions de contrôle comportant la gestion des missions pour utilisateurs, plus de
Postgre SQL.
automatisé effectuer les contrôles mobiles ainsi que les fonctionnalités
outils d’analyse des tournées (suivi des importantes
réalisations et de bilan des exécutions) envisagées après
2021
Android, Widget
S2 tablette de Logiciel embarqué dans les tablettes Déployé et
tomtom
navigation réalisant l’interface entre le système de fonctionnel avec le
navigation (tomtom) et le front S2. MDM sur les
tablettes tomtom. En
Il permet de récupérer les parcours définis
cours de refonte pour
sur le S2, de faire des alertes au
être déployé sur tout
coordinateur, de remonter les fichiers de
type de support
missions
Android.
GLPI + WS avec
S9 assistance Outil de ticketing et capitalisation (base de GLPI : en production
le SSO.
utilisateur GLPI connaissance) sur les réponses des et en interface avec
demandes de support (glpi). le SSO
Gère aussi le parc des tablettes Dexter.
Spring Boot,
S10 GMAO d’interface Supervision par le DCA des stocks DCA et Déployé seulement
Angular;
Logistique et stocks. des demandes d’approvisionnement du MO entre le mainteneur
PostgreSQL.
vers les constructeurs MAF. Contient le des radars fixes et
référentiel des pièces détachées des ET. les fabricants de
Permet de réaliser des alertes sur seuil du radars associés
niveau des stocks. Fait l’interface avec les (MAF).
GMAO des titulaires via les échanges de
Reste à déployer sur
fichiers CSV.
les autres
mainteneurs
déplaçables
Vertigo/Strut ;
S41 maintenance des Système de gestion des opérations Déployé
Open Layer ;
panneaux et maintenance sur les panneaux pour gérer complètement à tous
Postgre SQL.
consultations des ET les demandes d’intervention (maintenance les utilisateurs
préventive ou corrective) ainsi que la
consultation des fiches panneaux et des
fiches ET.
Contient aujourd’hui le référentiel commun
des panneaux.
ITEROP
Workflow métier Outil sur étagère permettant au métier Déployé à tous les
sans les équipes SI de designer un utilisateurs sauf
processus de manière graphique et de le DDT.
mettre en production. Il intègre les outils de
Non interfacé avec le
formulaire, de notification (mail), liste des
SSO du projet ou
tâches, suivi des processus.
d’autres outils.
Il est utilisé pour l’administratif (suivi des
Développé et
bons de commandes, validation des
maintenu par
services faits) et le déploiement de certains
l’éditeur.
types d’ET.
Il ne permet pas de mettre à jour un
référentiel de donnée.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 19 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Outils transverses
métier
Vertigo/Struts ;
Portail SI DCA, SSO Permet l’accès à l’ensemble des modules Déployé et mis à jour
PostgreSQL
gestion des utilisateurs applicatifs régulièrement (TMA)
Keycloack.
Centralise la gestion des utilisateurs
(activation/désactivation) et permet une
authentification unique, gère le
profil/habilitation des utilisateurs sur toutes
les applications sauf GED et ITEROP
Spring ;
Référentiel des ET Référentiel commun des applications En production depuis
constitué des données ET et dans le futur PostgreSQL. juin 2021 en
des données panneaux et des interface avec le S41
emplacements ETC déployés sur le uniquement et
territoire. contient que les ET
avec les données
fournies par les X-
PILOTE.

Spring ;
Référentiel des Intégré au portail il permet de définir le En production depuis
PostgreSQL.
marchés périmètre des équipements auquel un mars 2021 intégré au
marché peut accéder et d’afficher les portail.
informations en fonction de ce périmètre.

Outils transverses
soutien

Administration des Optimiser l’affichage en ligne de la Geoserver Déployé et utilisé par

couches cartographie en provenance de l’IGN et des toutes les
géographiques couches métiers des systèmes applications en
production

Traçabilité Permet de centraliser toutes les traces En production et

fonctionnelles de chaque système utilisé par les
systèmes 1,2 et 41

To do Liste des actions à réaliser par les En production et

utilisateurs avec lien vers l’action. utilisé par les
systèmes 1, 2, 41.

Notifications Permet de centraliser toutes les Redis Développé sur tous

notifications de chaque système et de les sous-systèmes
réaliser des notifications par mail.

Editique Edition des données data, image des Apache Birt En cours
systèmes dans une matrice paramétrable et d’intégration dans le
au format pdf permettant l’impression. S1

Bibliothèques de Librairie commune aux systèmes Spring/Angular 2 librairies, une par

modules permettant de garantir l’homogénéité de la framework.
Vertigo/Strust
conception visuelle des applications.

MDM Mobil Iron Store logiciel hébergé dans le cloud Mobil Iron Déployé
permettant de gérer à distance les mises à
jour des tablettes de navigation DEXTER

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 20 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

4.2.2 LA PLATEFORME DE MAITRISE ET VALORISATION DE LA DONNEE (PMVD)

Cette plateforme de donnée construite en premier lieu pour les besoins du DCA et de l’ONISR. Le
nom technique utilisé dans l’architecture de cette plateforme est Data-SR, raison pour laquelle on
retrouve ce terme dans certains schémas.
L’objectif de cette plateforme est la récupération de données brutes (données trafic, données VMA,
référentiel des radars et de leurs statuts, données réseaux,…) permettant d’être mises en forme pour
différents besoins :
- des proof of concept POCs et études par des data-scientistes ;
- des constructions d’indicateurs par les opérationnels métiers ;
- l’industrialisation d’indicateurs data, graphique et cartographique pour être consommés par
des systèmes externes avec de nombreux utilisateurs.
La plateforme PMVD a son propre Tenant dans le cloud PI et elle est décomposée en plusieurs
couches fonctionnelles :

Outils Objectifs métiers Socle technologique État d’avancement

Management de la Gouvernance des données, Non défini Choix des outils non
donnée (Dictionnaire, construction des datamarts arrêté.
qualité, lignage)
Interfaces avec les SI de données
Récupération des Nifi, kafka Installé
données
Traitement des données brutes
Réconciliation Hive Installé
technique archivage
Ceph
Apache HBASE
Socle informationnel
Réconciliation Hive, hadoop, Installé
fonctionnelle HBASE, Apach
Spark
Oozie : non installé
Vues subjectives (datamart,…)
Subjectivation métier Postgrsql, Apach Installé
Spark
Faire des propositions de
Algorithmie et Datalab Jupyter installé Partiellement
renforcement de zone de contrôle à
installés
partir d’analyse multicritères ? Dataiku non installé
Calculer des indicateurs et
Outils des restitution Tableau En cours
construire des tableaux de bord
des données d’installation
Grafana

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 21 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

4.3 LES OUTILS NON MIS EN TMA

Les systèmes présentés ci-dessous sont à l’arrêt et pourraient être relancés suite à une validation
d’un recadrage sur le besoin, le périmètre et les coûts. Les codes sources et documentations seront
fournies au titulaire :

Systèmes Objectifs métiers Socle État d’avancement

technologique

S7 aide à la C’est la partie IHM ouverte à un grand nombre de Non déployé Non développé
décision et la plateforme DATA PMVD pour les utilisateurs
reporting occasionnels.
transverse
Il permet d’afficher les données et tableaux de
bords, comprenant des fonctions de collecte et
d’exploitation simple des données (affichage et
requête) ainsi que des fonctions d’analyses
statistiques permettant aux utilisateurs la
consultation d’indicateurs historiées.
Spring/Angular;
S13 Système de gestion de déploiement et vie du parc Reprise d’une partie
Open Layer ;
déploiement incluant le pilotage de demandes de travaux (suivi des fonctionnalités
PostgreSQL.
vie du parc de l’instruction de l’expression de besoin sécurité pour une fonction de
ou d’un événement de maintenance jusqu’à la « Guichet Unique »
mise en service) sur un ensemble
d’emplacements et intégrant les nouvelles
générations de radars dont les déplaçables et
multi-infraction (ETT Équipement de Terrain
Tourelle, ETU Équipement de Terrain Urbain,
ETD2F Équipement de Terrain Discriminant
Double Face).
Vertigo/Struts ;
S31 gestion Système de gestion des VMA (Vitesse Maximale Mise à l’arrêt suite à
Geoserver ;
de la VMA Autorisée) permettant le calcul et l’exploitation de expérimentation et
Open layer ;
GV base de données VLA. Ce système permet difficulté de
PostgreSQL.
également de colleter et de publier les VMA l’enrôlement
auprès des gestionnaires de voirie. utilisateur.

S32 Ce système devait permettre de générer un Spring, L’orchestrateur a été

Orchestration référentiel de données VMA à partir des bases et développé, les
Airflow,
du calcul de batchs IGN, de la base panneau VLA transmis par batchs IGN
la VMA les kits d’externalisation des ETM. Deux bases PostgreSQL également. Reste les
devaient être produites, une base pour l’open data tests d’interface et
et base VLA « de contrôle » à destination des d’intégration avec le
ETM. titulaire du Kit
d’externalisation.
Projet à l’arrêt
Spring / Angular ;
S42 Système de gestion des opérations de Développé
Open Layer ;
maintenance maintenance sur radars pour gérer les demandes partiellement mais
PostgreSQL.
des d’intervention et de mise en service (maintenance stoppé pour ré-
équipements préventive ou corrective, mise en production). urbanisation
de terrain
Spring / Angular ;
S43 Système pour le paramétrage et l’envoi de Développé
PostgreSQL.
paramétrage commandes aux ET permettant leur exécution en partiellement mais
et envoi de télémaintenance : consultation/modification des stoppé pour ré-
paramètres légaux, mise en service, mise hors

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 22 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

commandes production, mise en production urbanisation

S5 plan de Système de pilotage de la rotation des dispositifs Vertigo La partie radars

contrôle de contrôle (ETC, UCA ETT et ETU) depuis la autonomes a été
demande préfecture jusqu’à la validation de la développée et
mise en place du contrôle par les titulaires de arrêtée lors de
marchés par le DCA prestataires l’expérimentation.
La partie radars
leurres n’a pas été
spécifiée.
Projet à l’arrêt

Notation POC réalisé à partir d’algorithme de « machine A abandonner

photo learning » permettant d’automatiser la notation
des photos des radars selon une grille
multicritère. Non industrialisé en raison de
l’architecture pour récupérer le flux de photos.

4.4 OUTILLAGE ET SOCLE D’INGENIERIE

Les outils actuellement utilisés dans le cadre du programme des outils SI du CA sont listés dans le
tableau ci-après ; ils peuvent faire l’objet de discussions ou de propositions de la part du titulaire, en
particulier pour les axes d’amélioration déjà identifiés (voir au sein du tableau).
Le cadre de cohérence technique (CCT) du ministère de l’intérieur figure en annexe 4. Tout outil,
même présent dans ce CCT, que souhaite utiliser le titulaire est soumis à la validation préalable de la
DNUM.

Thématiques Outils recensés Axes d’amélioration

Conception et Geoserver, OpenLayer, Spring, Prévoir la migration de

développement des outils Airflow, Spring Boot, Bugzilla Vertigo/Struts vers
numériques Angular/spring
Framework ancien : Vertigo/Struts
Nouveau framework (systèmes
déployés depuis début 2020) :
Angular JS/Spring

Tests et recette HPALM (utilisé par Sopra Steria), Mieux industrialiser

Jenkins l’automatisation des tests.

Gestion et configuration du GitHub GitLab (DAT) Sans objet

packaging

Qualité SONAR Cube

Espace collaboratif du projet GED projets (travaux) : TEAMS/ Les outils GED pour le
SI Sharepoint AMOA DCA présent projet sont
susceptibles d’évoluer.
GED dans le portail :
Alfresco/Cadocs : (pour le besoin
métier du DCA, actuellement non
utilisée)

Documentation Les cadrages des spécifications Le titulaire pourra proposer

sont réalisés dans des PowerPoint. des évolutions en
particulier pour mieux

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 23 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Les US sont rédigés dans JIRA tracer le lien entre le

cadrage avec le DCA et
Le référentiel architecture est rédigé
les spécification
sous des documents de traitement
techniques (US) fournies
de texte (Word) et des schémas
aux développeurs.
VISIO
Les règles de gestion et le lien avec
les IHM et les US sont dans HP
ALM
Les supports de formation sont sous
PowerPoint.

Gestion du backlog AGILE JIRA pour la gestion du backlog, Le titulaire pourra proposer
des spécifications des tickets et du un outil de collaboratif.
contenu des versions. Hébergé chez
l’AMOA du DCA.

Sécurité/chiffrement/antivirus ZED ! ; Client ClamAV ; (appliance Non identifié

virtualisée) ; Acid Cryptofiler

BDD PostgreSQL, REDIS Non identifié

Outils de ticketing Développement : JIRA Non identifié

Utilisateurs : GLPI (remontée des
anomalies utilisateurs via le portail),
Infra DNUM : ITSM (DNUM) (envoi
de tickets pour les différents
besoins)

Plateforme Technique

Supervision du système et Kibana, Logstash, decision Insight, Sans objet

des applications

Automatisation du Puppet Cet Outil n’est plus

déploiement des versions maitrisé par la DNUM et il
faut envisager une
migration vers ANSIBLE.

Bus de service Service Mix Supervision des interfaces.

Déployé partiellement (3
interfaces), permettrait de
gérer des interfaces
asynchrones.

Administration et contrôle Wallix Sans objet

des accès cloud

Supervision des flux avec les Axway Sans objet

équipements

Référentiel des données Nexus Sans objet

techniques applicatives

Certificats AC Certigna

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 24 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

AC du Ministère de l’Intérieur
AC de l’ANTAI
AC puppet (autosignés)

Autres outils Module de notation Bigdata (POC)

4.5 LES PLATEFORMES POUR LES OUTILS DU SYSTEME D’INFORMATION

État des lieux
Actuellement les environnements de développements et de tests de l’AMOA (hébergés sur les
infrastructures de l’AMOE actuelles) ne reflètent pas les environnements du cloud PI. La livraison
dans les environnements du CLOUD est lourde obligeant le projet à faire une première recette sur les
environnements de l’AMOE, puis une seconde recette sur les environnements du cloud. Lors de cette
seconde recette il apparait régulièrement des anomalies ou des difficultés d’intégration que l’AMOE
n’arrive pas à reproduire sur ses environnements.
Pour améliorer le process un projet de FORGE et de plateforme d’intégration continue applicative a
été envisagé mais le chantier n’a pas été lancé. Deux difficultés expliquent la non réalisation de ce
projet :
- la logique voudrait de mutualiser l’investissement avec la FORGE DNUM, cependant elle n’est
pas ouverte sur internet pour des raisons SSI et les équipes du titulaire ne seront pas
hébergées au ministère. En effet, la FORGE DNUM est mutualisée avec des applications très
sensibles ne permettant pas cette ouverture ;
- l’outillage retenu par le projet SIDCA en 2016 mis en place pour automatiser les tâches de
distribution sur le CLOUD (Puppet, etc.) n’est pas le choix retenu finalement par la DNUM.
Evolutions de l’architecture
Sur tous les environnements, le titulaire reprend la documentation technique (DAA, DAT, DAG,…)
existante et a la charge de sa mise à jour et de son évolution ou de sa création pour répondre aux
besoins des projets quel que soit l’hébergement des outils retenu par la DCA.
Il réalise ces prestations en collaboration avec les architectes de la DNUM.
Il s’assure que les choix techniques qu’il propose pour répondre aux besoins du DCA correspondent à
la politique de la DNUM (CCT,…) et qu’ils sont validés par la DNUM d’un point de vue état de l’art et
pérennité d’exploitation et maintenance.
Environnements de développements, tests
Au titre du présent marché, le titulaire met en place et héberge les plateformes de développement,
tests,… nécessaires pour garantir la qualité de sa prestation (voir § « XI - PRESTATION 1 (P1) :
INITIALISATION ET PRISE DE CONNAISSANCE »).
La plateforme du titulaire et la forge applicative mises en place pour les développements (voir § « XVI
- PRESTATION 6 (P6) : MISE EN PLACE ET MAINTIEN EN CONDITION OPERATIONNELLE DE
L’USINE LOGICIELLE Ŕ GESTION ET HEBERGEMENT DE L’OUTILLAGE DU SI ») doivent être
représentatives des environnements utilisés par le ministère en recette et production de manière à ce
que le titulaire puisse reproduire et anticiper toutes les anomalies qui pourraient apparaitre en
plateforme de production.
Le titulaire propose un mécanisme de déploiement entre ses environnements et ceux du ministère
(plateforme d’intégration) permettant de se rapprocher le plus possible d’une plateforme d’intégration
continue tout en répondant aux exigences de sécurité du ministère de l’intérieur.
Les interconnexions entre la plate-forme du titulaire et celle la plate-forme d’intégration doivent passer
par un mécanisme de communication sécurisé.
A noter que les environnements mis en place par le titulaire pourraient être intégrés dans une
plateforme d’intégration continue au cours du marché.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 25 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Les environnements décrits ci-dessous sont à la charge de l’administration et sont hébergés sur le
cloud PI de la DNUM. Cependant, le DCA peut décider en cours de marché de faire héberger une
partie des outils sur un autre cloud, soit sur la prochaine évolution du cloud PI, soit sur un cloud
externalisé répondant aux mêmes exigences de sécurité (cloud cercle 3).
4.5.1 LES ENVIRONNEMENTS DANS LE CLOUD PI

Leur architecture s’articule comme suit :

Figure 2 : Présentation générale de la plateforme

La plateforme est organisée autour de 3 zones :

 la zone 1, correspond à la zone hors production ;
 la zone 2, correspond à la zone de production privée ;
 la zone 3, correspond à la zone de production publique, accessible depuis internet.
La communication interzone, et avec l’extérieur, se fait par le biais d’une chaîne de services.
Chaque rectangle correspond à une machine virtuelle (VM) distincte.
Un des objectifs de cette architecture est de limiter le nombre de référentiels. Ainsi, seul un (1)
environnement (le tenant technique de production publique) contient le référentiel de sources, et le
référentiel de données n’est présent qu’à trois (3) emplacements, les deuxièmes et troisièmes se
synchronisant automatiquement avec le premier.
Un autre objectif est de mettre en place une architecture qui permette, dans le cadre d’un déploiement
automatisé, d’avoir un environnement de production rigoureusement identique aux autres
environnements (à l’exception potentielle du dimensionnement des machines).
Pour atteindre ces objectifs, une architecture avec des environnements techniques a été retenue,
chaque zone comportant un unique environnement technique.
Pour les tenants, on retient trois cas de figure distincts :
 le tenant technique de la zone de production publique : tenant technique principal ;
 les tenants techniques de la zone de production privée, et de la zone de
test/recette/qualification : tenants techniques secondaires ;
 les tenants non techniques.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 26 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Figure 3 : Architecture du tenant technique principal

Le tenant technique principal comporte tous les éléments techniques nécessaires au déploiement et à
la gestion des environnements fonctionnels. Il est notamment le seul à héberger un référentiel Git.
Il comprend en outre un serveur d’AC Puppet pour l’authentification entre les machines.

Architecture d’un tenant technique secondaire

Figure 4 : Architecture des tenants techniques secondaires

Les tenants techniques secondaires servent de relais pour les flux GitLab, et synchronisent leur Nexus
au tenant technique principal.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 27 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Ils comprennent également un serveur d’AC Puppet pour l’authentification des machines. Ainsi, les
différents environnements comportes des AC différents, évitant les risques liés à la duplication des
certificats entre les environnements.

Architecture d’un tenant non technique

Figure 5 : Architecture des tenants non techniques

Cette architecture est rigoureusement la même pour tous les environnements (production et hors
production), limitant ainsi les problématiques de déploiement.
Le schéma suivant précise les différents environnements créés avec l’objectif initial d’avoir une
plateforme d’intégration continue et tous les environnements permettant de gérer les opérations de
manière indépendantes.
En fonction de la trajectoire du projet, une optimisation des environnements et des VM sera à
proposer par le titulaire afin d’optimiser les coûts de fonctionnement .

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 28 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Figure 6 : Les environnements mis en place dans le cadre du projet SIDCA

Les différents environnements sont les suivants :

 INT : Tenant d’intégration permettant l’intégration des livrables ;
 DEV : Tenant de développement permettant aux développeurs de tester leurs
développements ;
 QUAL : Tenant de qualification permettant d’exécuter les tests automatisés sur les
applications ;
 REC : Tenant de recette permettant de valider fonctionnellement les applications avant leur
mise en production ;
 PREPROD : Tenant de préproduction, iso à la production, permettant de reproduire les
problèmes rencontrés en production en vue de leur correction, de réaliser des tests de
performances et de faire une répétition des mises en productions ;
 (R2)PROD : Tenant de production;
 FORM : Tenant de formation ;
 (R2)TECH : Tenant Technique embarquant l’outillage de déploiement automatisé ;
 DATASR : Tenant de la plateforme Big Data du DCA ;
 Les tenants préfixés ZPR sont les tenants correspondants pour la zone 2 (Zone PRivée) ;
 Les tenants préfixés R2 sont les tenants du PRA/PRI, situé sur la seconde région Cloud.
Les interfaces avec les SI externes sont les suivantes :
 IGN : les appels à destination de l’IGN, cartographie Grand Public et API DSR, transitent par
en interne DNUM et Internet. Tous les tenants SIDCA peuvent ainsi techniquement
s’interfacer avec n’importe lequel des environnements IGN ;
 ANTAI : les échanges avec l’ANTAI sont assurés au travers de la plateforme d’échange de la
DNUM, INES. Les accès à INES sont cloisonnés au niveau réseau :
o les tenants de la zone 1, hors production, peuvent accéder uniquement à INES
qualification et donc au travers de ce dernier aux environnements pré-production ou
recette de l’ANTAI ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 29 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

o les tenants de la zone 2 et 3 accèdent à INES production et donc au travers de ce

dernier à l’environnement de production de l’ANTAI (NB : l’environnement de formation
se situant dans la zone 3, il est donc interconnecté à la production ANTAI) ;
 Réseau Radar / TELCO3 : TELCO est l’opérateur des liens de communication entre les
équipements de terrain (radar, tablette, …), le CNT et la DNUM. Il assure une liaison
sécurisée de bout en bout. Les liens sont redondés entre TELCO et les SI correspondant au
site principal et de secours du cloud PI. Le nombre d’environnement connecté au réseau
radar est limité à 2 ;

 Prestataires des véhicules mobiles : titulaire du marché des kits d’externalisation pour la
récupération des données VLA.

V. DÉCOUPAGE DES PRESTATIONS

La liste des prestations du présent marché est la suivante :

PRESTATION OBJET

PRESTATION 1 (P1) Initialisation et prise de connaissance

PRESTATION 2 (P2) Conception et développement de projets

PRESTATION 3 (P3) Prestations spécifiques à la PMVD

PRESTATION 4 (P4) Tierce maintenance applicative

PRESTATION 5 (P5) Expertise technique et en architecture

PRESTATION 6 (P6) Mise en place et maintien en condition opérationnelle de l’usine logicielle -

Gestion et hébergement de l’outillage SI

PRESTATION 7 (P7) Réversibilité et transfert des acquis

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 30 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

VI. GOUVERNANCE
La gouvernance du SI, telle qu’illustrée ci-après, s’organise :
- au niveau du SI global ;
- au niveau contractuel ;
- au niveau projet.
Le pilotage ne fait l’objet d’aucune prestation individualisée. En tout temps de l’exécution du marché,
le titulaire doit intégrer la totalité des charges de pilotage aux prestations sans qu’il puisse réclamer, à
ce titre, aucun règlement d’aucune sorte en supplément du prix des prestations tel que fixé à l’annexe
financière à l’acte d’engagement.

Figure 7 : Synthèse de la gouvernance

6.1 GOUVERNANCE DU SI GLOBAL

La gouvernance du SI global concerne la conduite et le pilotage global du programme relatif à
l’ensemble des projets du système d’information des outils numériques du contrôle automatisé, à
savoir les projets de nouveaux outils et la TMA des outils en production.
Elle est assurée par trois instances et un point planning spécifique :
 un comité de pilotage (COPIL) :
o objectifs : faire le bilan des chantiers menés sur la période passée et fixer la feuille de
route de la période à venir en priorisant les chantiers à mener ;
o organisateur(s) : DCA ;
o participants : DCA MOE (DNUM), le titulaire ;
o contributeurs : tous les participants ;
o fréquence : trimestrielle.
Des comités de préparation sont organisés autant que nécessaire en vue de la tenue du COPIL.
 un « point planning » :

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 31 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

o objectifs : faire le point sur l’avancement de la réalisation, le contenu et la priorisation

des projets tels qu’acté lors du COPIL, faire le rappel du planning des travaux et
valider les propositions de modifications de planning, exposées et justifiées (dans le
cadre de la démarche Agile, cela correspond à la revue du Backlog) ;
o organisateur(s) : DCA ;
o participants : DCA, MOE (DNUM), le titulaire ;
o contributeurs : DCA, le titulaire ;
o fréquence : tous les 1,5 mois ;
 un comité de suivi (COSUI) :
o objectifs : faire le suivi opérationnel des projets en cours de développement et de la
TMA ;
o organisateur(s) : DCA ;
o contributeurs : DCA, le titulaire ;
o participants : MOA (DCA), MOE (DNUM), le titulaire ;
o fréquence : hebdomadaire, à adapter en fonction des besoins ;
 un comité technique (COTECH) :
o objectifs : conseil, arbitrage et validation des choix techniques ;
o contributeurs : DCA, MOE (DNUM), le titulaire ;
o organisateur(s) : le titulaire ;
o participants : MOA (DCA), MOE (DNUM), AMOA, le titulaire, experts en fonction des
besoins (BIE, architectes, RSSI, etc.) ;
o fréquence : mensuelle.
Le titulaire s’engage à assurer l’organisation (préparation des supports, organisation logistique,
rédaction des comptes-rendus) de l’instance dont il a la charge, à contribuer à la préparation des
instances sur demande de l’administration, et à participer aux instances auxquelles il est convié.
6.2 GOUVERNANCE CONTRACTUELLE
La gouvernance du présent marché est assurée par un comité contractuel mensuel, organisé par le
titulaire, dont les objectifs sont :
 le suivi de l’avancement des travaux planifiés ;
 le suivi des indicateurs qualité et opérationnels ;
 l’examen des résultats et des difficultés majeures rencontrées et soumises à arbitrage ;
 l’examen des questions financières du programme et des projets (charges, budget,
ressources et compétences dédiées) et du bilan de la facturation.
A ce titre, le titulaire fournit au MI, au minimum et pour chaque comité contractuel :
 le suivi des actions mis à jour sous forme d’un tableau de bord complet d’avancement de
l’ensemble des prestations du présent CCTP ;
 l’ensemble des indicateurs de suivi lui permettant d’avoir pleinement connaissance de
l’avancement du projet, des actions menées et des actions restant à mener.
Ces livrables prennent la forme d’un dossier de pilotage (voir § 10.4 « Dossier de pilotage, tableaux de
bord et indicateurs »).
Le titulaire propose les outils de suivi de projet (tableau de suivi des travaux et des risques, tableau de
bord des livrables, indicateurs, autres) qui doivent être validés par l’administration lors de la phase de
lancement (voir § XI « PRESTATION 1 (P1) : INITIALISATION ET PRISE DE CONNAISSANCE »).

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 32 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Le comité contractuel se réunit tous les mois et, en fonction des besoins, il peut être convoqué de
manière exceptionnelle par le MI.
Il est composé comme suit :
- Pour le ministère :
 DNUM ;
 invités selon ordre du jour.
- Pour le titulaire :
 directeur de mission, chargé des relations contractuelles avec le ministère, garant de la
qualité de la prestation,
 chef(s) de projet,
 experts invités selon l’ordre du jour.
Le titulaire est chargé de réaliser les supports d’animation du comité (à adresser aux membres du
comité au plus tard 2 jours ouvrés avant la réunion) et de rédiger les relevés de décisions du comité.
Le relevé de décisions doit être établi dans les 3 jours ouvrés qui suivent le comité. Sans remarque
des participants dans les 5 jours ouvrés suivants, le relevé de décisions est considéré comme
approuvé. Le délai de correction éventuelle du titulaire est de 1 jour ouvré.
6.3 GOUVERNANCE DES PROJETS
Cette gouvernance est relative à chaque projet.
Elle intéresse plus particulièrement les points de rendez-vous relatifs à la démarche de
développement tels que décrits au § VII « DÉMARCHE DE CONCEPTION, DÉVELOPPEMENT » du
présent CCTP.

VII. DÉMARCHE DE CONCEPTION, DÉVELOPPEMENT

7.1 PRINCIPES DE LA DEMARCHE
Le DCA retient deux types d’approche pour le développement des projets : soit selon un cycle en V,
soit selon une démarche semi-Agile.
Le choix de la démarche de développement est fait en fonction du type de projet, que ce soit pour le
développement de nouveaux projets ou pour les évolutions de projets dans le cadre de la TMA.
Dans le cas des projets en V, les spécifications techniques détaillées sur l’ensemble de l’applicatif
sont produites par le proxyPO avec des séances de validation avant le développement. Le titulaire
procède au développement complet du projet et à l’issue, livre une version finale mise en recette.
La démarche applicable dans le cadre du présent marché et pour la conception et le développement
d’un projet d’outil logiciel, compte trois (3) grandes étapes :
 une étape d’élaboration des spécifications fonctionnelles générales globales au projet
et de cadrage de l’étape de conception/développement :
sur la base d’un périmètre métier cohérent et intègre, cette étape a pour but :
o d’élaborer la spécification fonctionnelle générale du périmètre métier ;
o de dresser un calendrier de réalisation, avec une vision du nombre de sprints, des
équipes à mettre en place et du nombre d’itérations nécessaires pour atteindre les
objectifs de la version finale à livrer ;
o le cas échéant, d’identifier des versions intermédiaires à livrer en production.
Cette étape se réalise par la maîtrise d’ouvrage, avec son AMOA et les directions métiers. Le titulaire
du présent marché y contribue, en particulier sur le chiffrage et le délai.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 33 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Dans le cadre d’un développement en mode Agile, la démarche résultant de cette étape pose
également le niveau de vélocité à atteindre lors de l’étape de développement sur la base des
développements précédents (voir § 7.3.2 « Vélocité »).
 une étape de conception technique et de développement :
Une fois l’étape précédente aboutie, la conception technique et le développement se réalisent selon le
calendrier validé lors de l’étape précédente, et dans la démarche Agile présentée au § 7.3 « Étape de
conception technique et de développement agile » ou selon une approche en cycle en V comme
présenté au § 7.4 « Étape de conception et de développement en cycle en V ».
Le titulaire est chargé de cette étape, et l’administration s’assure du respect du calendrier et vérifie
l’atteinte ou non des niveaux de vélocité (voir § 7.3.2 « Vélocité ») retenus lors de l’étape précédente
(s’il est en cycle Agile).
 une étape de validation de version et de mise en production (VA, VSR) :
Quel que soit le mode de développement retenue (cycle en V ou mode Agile) dès qu’une version est
livrée par le titulaire, elle est installée sur une plate-forme de l’administration et/ou du titulaire et donne
lieu à une phase de vérification d’aptitude (VA). Si la décision de vérification d'aptitude est positive, la
vérification de service régulier (VSR) débute.
7.2 ROLE DES ACTEURS
Les processus utilisés sont issus des méthodes agiles comme Scrum ou Kanban et s’adaptent à la
progression du SI. Un passage à une méthodologie de type Agile « à l’échelle » est aussi
envisageable.
La méthode Agile envisagée dans le cadre du présent marché doit respecter les éléments clés
exposés ci-après.
Les agents de l’administration sont au centre du programme. L’administration et le titulaire s’attachent
à renforcer la maîtrise du SI cible par les agents de l’administration.
La direction du programme est assurée par le DCA. La gestion des produits (product manager) de
l’ensemble des outils est assurée par le DCA. Le product manager (ci-après PM) représente les
métiers et les utilisateurs de l’outil. Il est chargé de la définition et la priorisation des features
(fonctionnalités), en collaboration avec les products owners des équipes. Il donne la vision globale du
produit.
La mission de product owner (ci-après PO) d’un projet est assurée par le DCA. Le PO :
 porte la vision du produit constitué par l’application ;
 est l’expert métier du domaine : à ce titre il participe à la rédaction des exigences
fonctionnelles (fonctions et interfaces) sous la forme de user stories et participe à leur
déclinaison au sein du backlog sprint. Le backlog sprint est un sous-ensemble du
backlog product, il donne le contour fonctionnel et technique du sprint (itération) ;
 est responsable de la planification de la réalisation des fonctionnalités et de la gestion des
versions qui les portent. Il assure donc, avec les équipes du titulaire chargées du
développement et de l’intégration, la priorisation du backlog produit en vue des itérations
(« backlog sprint »), packages (« backlog release ») et versions majeures ;
La fonction de co-product owner (ci-après CoPO) est assurée par le DCA ou son représentant.
Les fonctions de proxy product owner (ci-après proxyPO), de tech leader et de scrum master sont
assurés par le titulaire et font partie des équipes de développement :
 le CoPO et le proxyPO collaborent pour décrire le besoin métier. Le CoPO rédige en mode
itératif, la documentation fonctionnelle générale incluant les processus, les maquettes (etc.) et
la fait valider par le PO. Le proxyPo rédige les users stories (récits utilisateurs) déclinées du
document fonctionnel général. Le CoPO et le proxyPO peuvent mener ces travaux plus ou
moins en parallèle, ou en décalé suivant la maturité du besoin métier ; dans tous les cas
l’UX/UI (pris en charge par le DCA) est inclus dans ces travaux. Le CoPO relit et valide les
users stories rédigées par le ProxyPO, il complète si besoin les users stories ainsi que les
conditions d’acceptation ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 34 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 le « CoPO » organise les ateliers, la préparation de l’ordre du jour en collaboration avec les
équipes et la rédaction du compte rendu ;
 les scrums master sont responsables de l’application de la méthode Scrum et du bon
déroulement des développements. Ils sont aussi des référents techniques pour les équipes de
développeurs. Ils suivent les release, mesurent la vélocité, organisent les rituels et remontent
les informations au PM ;
 l’architecture technique et logicielle est assurée par le titulaire, en conformité avec les règles
prescrites par la MOE ;
 les normes et bonnes pratiques sont énoncées par l’architecte logiciel, en conformité avec les
règles prescrites par la MOE ;
 le modèle de base de données est sous la responsabilité du titulaire ;
 l’exploitation et l’intégration sont des fonctions assurées par la DNUM avec l’appui du titulaire ;
 si des agents de l’administration participent au projet, ils pourront se voir confier des missions
de proxyPO, de tech lead et de scrum master.
Le schéma ci-dessous résume ces grands principes :

Figure 8 : Rôle des acteurs dans le cadre d'une démarche Agile

Le titulaire met en place, en partenariat avec le DCA, une structure adaptée au projet, selon la
méthode Agile, en réponse à ces principes. L'équipe associée au programme est dédiée au
programme et dimensionnée afin de conduire dans les délais, et avec le niveau de qualité requis, les
prestations demandées. A cette fin, le titulaire dispose dans ses ressources internes, d'experts dans
chacun des domaines abordés par le programme. Le cas échéant, le titulaire doit être capable de
mobiliser les ressources nécessaires.
L’équipe du titulaire comporte, au sein de son ou de ses équipes, au minimum, les rôles suivants :
 proxyPO ;
 concepteurs / développeurs front et back end, qui réalisent, en plus des développements, les
tests qui y sont associés et rédigent la documentation technique ;
 tech lead / architecte : transverse à toutes les équipes, il assure le relai entre les
développeurs et garantit une qualité de service homogène ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 35 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 intégrateurs : transverse à toutes les équipes, en charge de l’intégration applicative des

différentes briques composant un projet ;
 scrum master.
7.3 ÉTAPE DE CONCEPTION TECHNIQUE ET DE DEVELOPPEMENT AGILE
L’administration a fait le choix d’un développement selon une méthode Agile, de type SCRUM.
Cependant, l’administration se réserve le droit d’opter pour une méthodologie de type Agile « à
l’échelle » au cours du marché.
Dans le présent document, les termes « itérations » et « release » sont utilisés pour caractériser
différentes étapes du projet et sont à rapprocher de notions utilisées dans la méthodologie Agile
Scrum.
Le terme « itération » est un nombre de « sprint » généralement utilisé pour caractériser les étapes de
quelques semaines de conception et de réalisation dans la méthode Agile Scrum.
Le temps de développement est divisé en « sprints » de deux (2) semaines :
 une itération est égale à deux (2) « sprints », temps entre deux démonstrations ;
 une démonstration et une rétrospective sont organisées à la fin de deux (2) sprints.
Le terme « release » (ou version) correspond à une livraison en vue d’une mise en production. Cela
correspond à la livraison de blocs fonctionnels complets.
Outre les développements, le titulaire effectue l’ensemble des tests usines correspondants (tests
d'intégration applicatifs) avant la prise en main par l’administration.
Le schéma ci-dessous fait la synthèse de la démarche :

Figure 9 : Synthèse de la démarche de conception et développement en mode Agile

La recette applicative des actions est effectuée par le titulaire ; la recette métier est effectuée par les
équipes de l’administration.
La mise au point des méthodes de développements, de l’application des méthodes Agile, de
l’évaluation des user stories sont décrites par le titulaire au démarrage du marché et intégrées dans le
plan de management projet (PMP) sous réserve de la validation préalable de l’administration.
CCTP-AMOE-SI Outils numériques du contrôle automatisé
P a g e 36 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

7.3.1 LES CEREMONIES AGILES

Les rituels Agiles ont lieu à l’échelle d’une équipe, dans le cadre d’un projet, ou de façon transverse.
Le titulaire s’intègre dans l’organisation définie dans le PMP produit par le DCA, auquel il apporte sa
contribution et qui se présente actuellement comme suit :

Figure 10 : Organisation des cérémonies Agile

Des rituels transverses concernent l’ensemble des équipes. Ils ont pour objectifs de :
 partager les retours d’expérience ;
 suivre les risques et les mitiger ;
 s'améliorer à l’échelle du programme ;
 montrer l'avancement au niveau programme ;
 partager les objectifs et les enjeux des travaux.
Les rituels concernés sont les suivants :
 les rétro-tech ;
 les rendez-vous CoPO/ProxyPO ;
 les démonstrations globales.
Le temps consacré à ces rituels est considéré comme du temps de développement.

7.3.2 VELOCITE

La vélocité est un indicateur important pour le fonctionnement de l’équipe. Chaque user story reçoit
une estimation sur la base d’une méthode Ŕ de type séquence de Fibonaci, sprint poker - qui sera
proposée par le titulaire et validée par l’administration en début de marché et inscrite au PMP. Seules
les stories correspondant à des évolutions fonctionnelles (hors US de correction des anomalies)
entrent en compte dans le calcul du nombre de points effectués dans une itération donnée.
Ce nombre de points effectivement réalisés est appelé « vélocité ». Cet indicateur peut varier d’une
itération à l’autre. Il est toutefois fiabilisé par une moyenne constituée au fil des itérations passées (au
CCTP-AMOE-SI Outils numériques du contrôle automatisé
P a g e 37 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

sein d’une équipe, elle est stabilisée à l’issue de la seconde itération). La vélocité permet
principalement de lever les incertitudes sur les développements à venir.
Cette vélocité est calibrée d’un commun accord entre l’administration et le titulaire en fonction de la
composition des équipes lors des premières itérations.
Chaque membre de l’équipe doit respecter la méthodologie et assurer ses activités afin de maintenir
la vélocité. Après la période de stabilisation (typiquement 2 itérations) la variation de la vélocité
ne doit pas dépasser 20% de la moyenne calculée sinon un sprint permettant d’absorber le
surplus est ajouté, il est à la charge du titulaire.
L’administration peut à chaque itération demander le remplacement d’un membre d’une équipe si elle
constate un manque de compétences techniques, de rigueur dans le respect de la méthodologie ou
tout autre manquement affectant la production ou la cohésion du groupe. Les modalités de
remplacement d’intervenant sont précisées dans le § 8.5 « Exigences sur les ressources du titulaire »
8.5.
7.4 ÉTAPE DE CONCEPTION ET DE DEVELOPPEMENT EN CYCLE EN V
La démarche débute à la livraison des spécifications fonctionnelles générales telle qu’évoquée au
§ «7.1- Principes de la démarche ».
Le titulaire prend en charge, dans le respect des conditions et des exigences de qualité de service du
marché, les étapes suivantes :
- conception technique détaillée ;
- codage ;
- tests unitaires ;
- tests intégration applicatifs des composants développés.
Chaque livraison des composants développés est inscrite au titre d’une version, dans le cadre d’un
dispositif de gestion de configuration.
Par ailleurs, le titulaire accompagne ses livraisons du plan de tests (préalablement validé par le DCA),
des jeux de tests techniques sur lesquels il s’est appuyé pour valider le bon fonctionnement des
composants développés par ses soins, de la description du contenu de ces jeux de tests et des
résultats obtenus lors de ces tests (nombre de lignes, PDF ; etc.).
D’autre part le titulaire est tenu de préciser la façon dont il a structuré les jeux de données afférents
aux tests.
7.5 ÉTAPE D’INTEGRATION SUR LA PLATEFORME DE L’ADMINISTRATION
Suite aux développements réalisés en cycle en V ou en méthode Agile, à réception des composants,
l’administration procède à une première installation et intégration sur une plate-forme de qualification.
Le titulaire procède à une livraison comprenant notamment le dossier d’installation à appliquer par les
équipes d’intégration et exploitation.
Les livraisons des composants applicatifs sur la plate-forme de qualification sont réalisées en
anticipant sur les délais d’installation, et en faisant en sorte que l’installation puisse être effective au
maximum 24 heures après la livraison.
A cet effet, le titulaire doit tenir compte des jours et heures de disponibilité des équipes en charge de
l’intégration.
De manière générale, les développeurs responsables des traitements et de la non régression du
système doivent se rendre disponibles la semaine qui suit la livraison ou le début d'exploitation des
traitements dont ils sont responsables.
7.6 ÉTAPE DE VERIFICATION (VA, VSR)
A la livraison d’une version ou « release », telle que planifiée au calendrier du projet, l’administration
procède à une vérification d’aptitude (ou VA) sur un environnement de « qualification/recette ». Cette
VA débute à partir de la confirmation par l’administration de la bonne installation de la version en
environnement de qualification/recette.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 38 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Le titulaire assiste, sans incidence financière, l’administration lors de la VA et réalise toutes les
corrections d’anomalies identifiées lors de cette phase.
L’administration se réserve le droit de rejeter tout ou partie d’une livraison si après une vérification
d’aptitude (VA), elle constate que tout ou partie ne répond pas à ses attentes ou n’a pas le niveau de
qualité suffisant. Dans ce cas, la livraison est rejetée et peut donner lieu à l’application de pénalités.
La durée de la VA est fixée à un (1) mois, et peut-être reprécisée/amendée pour chaque version.
Une fiche navette entre le titulaire et l’administration est suivie par le titulaire précisant les plannings
de livraison, les dates de début de recette, les durées de VA, les dates associées etc. Cette fiche
est revue en comité projet avec le DCA et soumise explicitement à validation.
En cycle Agile, une recette métier est réalisée en parallèle des développements. De ce fait, la VA
peut être écourtée à discrétion de l’administration.
A l’issue de la période de VA, le délai maximal imparti à l’administration pour notifier sa décision est
de dix (10) jours ouvrés. Durant cette période, la correction de toute anomalie reste à la charge du
titulaire dans les délais fixés par le marché (voir §8.9 8.9 « Délais de traitement des anomalies
applicatives »). La durée de résolution de toute anomalie bloquante ou majeure détectée prolonge
d’autant le délai de la VA, dans la limite d’une prolongation maximale d’un (1) mois). Au-delà du
mois, des pénalités peuvent s’appliquer.
Si la décision de VA est positive, la vérification de service régulier (VSR) débute.
A chaque livraison et mise en exploitation d’une version initiale, une période ferme de VSR de trois
(3) mois est observée. Pour les versions évolutives programmées et successives, la période de VSR
est réduite à 1 mois calendaire après la mise en production de la version et dans un délai maximum
de 3 mois après la fin de la VA.
Dans le cas d’une mise en production d’une version évolutive pendant la période de VSR, la VSR de
la version précédente court toujours sauf accord de l’administration.
Durant cette période, la correction de toute anomalie reste à la charge du titulaire dans les délais
fixés par le marché (voir § 8.9 « Délais de traitement des anomalies applicatives »). La durée de
résolution de toute anomalie bloquante ou majeure détectée durant la VSR prolonge d’autant le
délai de la VSR, dans la limite d’une prolongation maximale de trois (3) mois). Par suite, la durée de
la VSR ne saurait excéder six (6) mois, délai au-delà duquel des pénalités peuvent s’appliquer.
A l’issue de la période de VSR, le délai maximal imparti à l’administration pour notifier sa décision
est de dix (10) jours ouvrés.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 39 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

VIII. EXIGENCES
8.1 EXIGENCES GENERALES

Référence Description

EG1 Le titulaire met en place une structure adaptée au projet, selon la méthodologie Agile
et capable de fonctionner en cycle en V. L'équipe associée au projet est dédiée au
programme et dimensionnée afin conduire dans les délais, et avec le niveau de qualité
requis, les prestations demandées.

EG2 Afin de coordonner toutes les actions nécessaires à la bonne exécution du projet et
d'assurer sa pleine mission de conseil, le titulaire dispose dans ses ressources
internes, d'experts dans chacun des domaines abordés par le programme. Le cas
échéant, le titulaire doit être capable de mobiliser les ressources nécessaires.

EG3 Le titulaire s’engage à informer au plus tôt l’administration de tout changement de

personnel au sein de son équipe. En tout état de cause, le changement de personnel
ne peut impacter la bonne marche du programme tant en matière de délais que de
résultats.

EG4 Le titulaire s’engage à effectuer son devoir de conseil et d’alerte vis-à-vis de la DNUM,
de même, la DNUM s’engage à respecter son devoir d’information et de collaboration
avec le titulaire.

EG5 La DNUM se réserve le droit de conduire des audits à titre préventif ou en cas de non-
respect des dispositions de qualité liés au système dont le titulaire assure la
maintenance ou les évolutions, ou pour les procédés mis en œuvre pour le développer
ou le vérifier, et plus généralement la DNUM se réserve le droit de diligenter des
audits sur tout ou partie des prestations réalisées ainsi que sur les méthodes utilisées.

EG6 Suite à une demande d’audit formulée par la DNUM, le titulaire lui donnera accès sans
restriction aux locaux où se déroulent les prestations (si hors site de la DNUM), et à
toutes les informations concernant la prestation.

EG7 La DNUM s’engage à respecter la déontologie de l’audit.

8.2 EXIGENCES SUR LA DOCUMENTATION

Référence Description

ED1 Tout document fourni à la DNUM par le titulaire à titre provisoire ou définitif comportera
les informations suffisantes pour identifier sans ambiguïté ce document, sa version
(Vi.j), son degré d’achèvement, son niveau de vérification et la version de l’application
avec laquelle il est cohérent. Cette exigence s’applique à la documentation en ligne.

ED2 Toute modification apportée sur un document élaboré par le titulaire et déjà livré à la
DNUM dans une édition précédente sera identifiée explicitement dans le texte de la
nouvelle édition du document et tracée dans un historique.

ED3 Les informations contenues dans la documentation définitive fournie par le titulaire
devront être à jour, complètes, cohérentes et exemptes de toute annotation provisoire.
Elles devront éviter toute redondance injustifiée.
Le titulaire apportera la preuve de ses contrôles par la mention en tête de chaque
document des noms et qualités des relecteurs et de la date de validation par ceux-ci.

ED4 La transmission de cette documentation se fera telle que définie dans les plannings, et

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 40 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description
sera tracée lors des comités ad-hoc.
Le document désigne les destinataires.

ED5 Le nombre de documents à produire dans le cadre du marché et selon les travaux à
réaliser s’avère important (SFD, dossier de conception technique, guide utilisateurs,
notes diverses, manuels d’exploitations, DAT, etc.).
Par conséquent, le titulaire doit adopter une démarche permettant d’optimiser la phase
de relecture des documents et de validation des documents.
Il met en place à cet effet un espace partagé accessible par les différentes personnes
désignées par la DNUM.
Les principes suivants devront être respectés :
 chaque nouveau document à produire passe par :
o le respect du formalisme et de la structuration du document définis
par ou avec la DNUM ;
o une première étape de validation sur le plan, le contenu détaillé et la
forme du document (revue du sommaire, accord sur le contenu) ;
o le cas échéant, pour les documents volumineux, une deuxième étape
à mi-chemin pour contrôler l’état d’avancement du document et en
faire une première lecture ;
o une ultime étape de validation, une fois le document terminé du point
de vue de son rédacteur ;
 pour les documents faisant simplement l’objet de modifications (suite aux
évolutions du système), le titulaire fait en sorte que les modifications apportées
soient identifiables sans ambiguïté (mode correctif de MS Word par exemple) ;
 les documents dans une version définitive sont distingués des documents de
travail. Ces derniers d’une durée de vie limitée à une phase transitoire des
travaux ont pour vocation de produire un document définitif par création ou
modification. Seule la DNUM statue sur le caractère définitif d’un document.
Sa version antérieure peut éventuellement être sauvegardée ;
 l’ensemble des documents sont impérativement stockés dans espace proposé
et tenu à jour par le titulaire et accessible aux personnes désignées par la
DNUM ;
 tout livrable (SFD, dossier de conception technique, guide utilisateurs, notes
diverses, manuels d’exploitations, etc.) est obligatoirement transmis dans un
format bureautique (type MS Word) imprimable et modifiable, en sus d’une
livraison sous une autre forme (si applicable).
Le titulaire s’assure également que les évolutions / modifications ou ajouts de
documents au sein de l’espace partagé puissent générer une alerte auprès des
personnes de la DNUM concernées afin de les informer.
Le titulaire peut être force de proposition sur le sujet afin d’améliorer d’avantage ce
dispositif, et lisser dans la mesure du possible la charge inhérente de validation à
réaliser de la part de la DNUM.

ED6 Le titulaire assure la gestion de la documentation qui lui est confiée, et sa

confidentialité : des sauvegardes sont réalisées et les accès sont strictement limités
aux personnes habilitées.

ED7 Le titulaire utilise les outils de cryptage compatibles avec ceux de l’administration pour
les documents à accès restreint (DAT, DAA, etc.) définis avec la DNUM. Les outils

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 41 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description
utilisés sont :
 Acid Cryptofiler pour le MI ;
 Zed projet pour le programme et administré par le DCA ou son représentant.

8.3 EXIGENCES SUR LA CONDUITE DES PRESTATIONS

Référence Description

ECP1 Le titulaire assure le suivi détaillé de toutes les actions relatives au présent marché.
Il fournit à l’administration l’ensemble des indicateurs de suivi lui permettant d’avoir
pleinement connaissance de l’avancement du projet, des actions menées et des
actions restant à mener.

ECP2 Le titulaire veille à mettre à jour le suivi d’actions et à le rendre disponible de manière
dématérialisée à la demande de l’administration.

ECP3 A chaque comité contractuel, le titulaire fournit à l’administration un tableau de bord

complet d’avancement de l’ensemble des prestations du présent CCTP.

ECP4 Le titulaire propose les outils de suivi de projet (tableau de suivi des travaux et des
risques, tableau de bord des livrables, indicateurs, autres) qui doivent être validés par
l’administration lors de la phase de lancement.
Il devra fournir à l’administration un tableau de bord au minimum tous les 2 mois
(même en l’absence de comités).

ECP5 L’administration fournit l’hébergement et les licences des outils de gestion du backlog
et de la documentation de développement. Elle administre ces outils.
Le titulaire l’assiste dans l’administration et gère ces outils pour l’ensemble des acteurs
du projet.
Dans les quatre (4) premiers mois de sa prestation, le titulaire assiste l’administration
dans la mise en place des outils et assure la migration des US de l’outil JIRA actuel du
prestataire AMOA du DCA vers les outils hébergés par le ministère.
Les outils retenus pour le développement fonctionnel sont Confluence d’Altassian
(SFG, SFD) et JIRA. Le titulaire devra paramétrer ces outils pour permettre le même
niveau de qualité documentaire qu’exigé.
En parallèle une GED projet classique de la DNUM (OCMI ou RESANA) sera mise en
place dès le début du projet pour la gestion de marché, et pour les documents
sensibles d’architecture.

ECP6 Le titulaire s’engage à participer aux structures de pilotages et de revues permettant

de s’assurer du respect des exigences de la DNUM en matière de coût, de délai et de
qualité.

ECP8 Les tableaux de bord de suivi des prestations sont élaborés (sur la base d’un modèle
proposé par le titulaire).
Ce modèle doit être validé par la DNUM qui pourra en demander des évolutions
auxquelles le titulaire devra se conformer. Celui-ci présentera au minimum :
 pour les projets en cours de conception/développement :
o l’état d’avancement de développement par rapport au calendrier ;
o le niveau de vélocité atteint ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 42 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description
o le bilan des dernières livraisons ;
o le nombre d’anomalies et l’état d’avancement de résolution en
VA/VSR ;
 pour la maintenance corrective :
o nombre d’incidents réceptionnés mentionnant par type (bloquant,
prioritaire, non prioritaire) ;
o nombre de corrections d’incidents par type livrées et délais de livraison ;
o nombre d’incidents en cours de traitement par type et date ;
 pour la maintenance évolutive :
o demandes d'évolutions reçues, chiffrées, commandées, en cours de
réalisation, réalisées, livrées, délais de livraison, motifs d’éventuels
retards ;
o bilan des dernières livraisons ;
 pour les autres prestations :
o état d’avancement et/ou bilan.
Ces tableaux de bord sont présentés en COSUI et sont régulièrement tenus à jour par
le titulaire.
Pour le suivi de la qualité de traitement des demandes d’intervention ou de résolution
des incidents (anomalies applicatives) les indicateurs fournis sont mis à mis à jour
toutes les semaines.

ECP9 Après la période de stabilisation (typiquement deux itérations) la variation de la

vélocité ne doit pas dépasser 20% de la moyenne calculée sinon un sprint permettant
d’absorber le surplus est ajouté, il est à la charge du titulaire.

ECP10 La proportion réservée à la correction des anomalies pour un sprint ne peut excéder
20%. Au-delà, un sprint supplémentaire à la charge du titulaire est mis en œuvre pour
résorber le surplus d’anomalies.

8.4 EXIGENCES SUR LA GOUVERNANCE

Référence Description

EGV1 Le titulaire désigne un interlocuteur unique pour le suivi du marché. Il est le garant du
respect :
 de l’exécution des prestations ;
 du respect des niveaux de services ;
 de l’ensemble des exigences du marché ;
 du respect des normes, standards, méthodes et démarches mises en place
dans le cadre du marché.
Une attention particulière sera portée sur l’organisation de la gouvernance dans le
premier mois de mise en œuvre du marché, notamment sur la mise en place d’un plan
d’assurance qualité partagé par l’ensemble des acteurs.

EGV2 En cas de départ de l’interlocuteur unique pour le suivi du marché du titulaire, la

période de recouvrement pendant laquelle le partant forme la nouvelle personne
pressentie pour la conduite du projet, doit être au minimum d’un mois calendaire.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 43 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description

EGV3 Dans le cas d’un problème critique, identifié par la DNUM dans ses relations avec le
titulaire, ou dans le fonctionnement du système pour lequel la DNUM n’obtient pas
satisfaction de la part du directeur de projet du titulaire, le titulaire fera en sorte de
mobiliser et de mettre en contact sa hiérarchie (par exemple son directeur général)
avec le responsable de la DNUM concerné dans les 5 jours ouvrés à compter de la
date de notification du problème par la DNUM.

8.5 EXIGENCES SUR LES RESSOURCES DU TITULAIRE

Référence Description

ERT1 Le titulaire doit disposer de ressources suffisantes pour couvrir l’ensemble des
prestations de son lot. Les technologies sont, au minimum, celles qui figurent dans la
liste des applications du SI existant.

ERT2 Le titulaire respecte les règles de séniorité applicables au présent marché : définition
des quatre niveaux de séniorité (10.5.2) ; niveaux de séniorité imposés par prestation
(10.5.3).

ERT3 La DNUM peut à chaque itération demander le remplacement d’un membre d’une
équipe si elle constate un manque de compétences techniques, de rigueur dans le
respect de la méthodologie ou tout autre manquement affectant la production ou la
cohésion du groupe.

ERT4 Chaque remplacement doit être organisé de manière à limiter l’impact sur le
déroulement du projet. Le titulaire doit s’assurer d’un recouvrement pendant au moins
un mois entre l’intervenant sortant et l’intervenant entrant.
Les recouvrements ne donnent lieu à aucune demande de règlement d’aucune sorte
(seul un profil sur les deux est facturé).

ERT5 Le titulaire s’engage dès lors que son équipe est en place et convient à la DNUM, à
conserver celle-ci (sauf cas de force majeure ou démission du collaborateur) pendant
toute la durée du marché.

ERT6 En tout état de cause et en cas de départ d’un collaborateur du titulaire, celui-ci
tiendra informée la DNUM au plus tôt et justifiera de son départ.

ERT7 En cas de départ du collaborateur, le titulaire s’engage à le remplacer par une

personne au minimum de qualification identique ou supérieure et possédant toutes les
compétences en lien avec le marché.

ERT8 Chaque remplacement doit être organisé de manière à limiter les effets sur le
déroulement du projet. Le titulaire doit s’assurer d’un recouvrement pendant au moins
un mois entre l’intervenant sortant et l’intervenant entrant.
Les recouvrements ne donnent lieu à aucune demande de règlement d’aucune sorte
(seul un profil sur les deux est facturé).

ERT9 Les CV de tout nouvel intervenant en cours de marché doivent être soumis à
l’approbation de l’administration.

ERT10 Dans le cas d’une insuffisance ou d’un manquement dûment constatée par la DNUM
d’un intervenant du titulaire, d’un commun accord, ce dernier pourvoit à son
remplacement en satisfaisant au profil requis avec la remise à niveau nécessaire sans
coût supplémentaire pour la DNUM.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 44 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

8.6 EXIGENCES SUR LES MOYENS TECHNIQUES ET SUR LA COHERENCE DE L’ARCHITECTURE TECHNIQUE
GLOBALE DU SYSTEME D’INFORMATIONS

Référence Description

EMT1 Le titulaire s’engage à mettre en place des environnements de développement

répondant aux caractéristiques requises pour maintenir et faire évoluer le SI des outils
numériques du contrôle automatisé sur toute la durée du marché. Ces
environnements doivent être représentatifs des environnements de la DNUM pour
détecter et reproduire les anomalies.
Dans le cas où l’hébergement serait réalisé dans un cloud externalisé, le titulaire
prévoit une forge intégrée aux environnements externalisés.

EMT2 Le titulaire s’engage à maintenir les logiciels de développement, les applications et

l’ingénierie de développement dans des versions opérationnelles et compatibles avec
les environnements techniques permettant leur fonctionnement dans l’environnement
cloud retenu par la DNUM.

EMT3 Le titulaire s’engage, dès le début du marché, à assurer la maintenance du SI des

outils numériques du contrôle automatisé dans les environnements techniques qui
prévalent à leur fonctionnement.
Il est entendu que la DNUM se réserve le droit de faire évoluer ces exigences en
cours de marché, notamment lorsque celles-ci font référence à des solutions
techniques spécifiques.

EMT4 Tout composant développé ou nécessaire au bon fonctionnement ou à la compilation

des modules applicatifs développés pour le compte de la DNUM font l’objet d’une
cession de droit dans les conditions décrites dans le CCAP.

EMT5 Conformément aux stipulations du CCAP, la DNUM détient l’ensemble des droits de
propriété et de propriété intellectuelle du référentiel des développements. A cet égard,
elle doit être en mesure de reconstituer la mémoire des différentes versions des
composants applicatifs. La DNUM est en mesure de demander un retour à une
version antérieure d’un développement. Pour ce faire, tout changement dans un fichier
(commit) identifie la nature de la modification qu’il porte.

EMT6 Les tests sur la qualité du code, les tests unitaires et les scénarios de tests sont
indissociables du code source et des livrables. Le prestataire garantit leur exécution
avant tout livrable. Le titulaire systématise les balises permettant aux équipes de
recette du DCA d’automatiser les tests, en particulier les tests de non régression.

EMT7 L’environnement de développement, comme tout environnement applicatif, dispose

d’un document d’architecture technique, d’une procédure technique d’installation et
d’exploitation.
Elle permet la gestion et autorise le suivi de l’avancée de l’en-cours avec les versions
des composants applicatifs.
Elle est porteuse d’une mise en œuvre rigoureuse de l’organisation de projet et
particulièrement la mise en place de rôles précis (architecte, développeur, intégrateur,
Scrum master, etc.)

EMT8 Le titulaire assure le maintien en condition opérationnelle de l’ensemble des

infrastructures logicielles et matérielles (équipements serveurs et réseaux)
nécessaires au marché, notamment les produits logiciels correspondant à l’ingénierie
et aux solutions de développement utilisées par le titulaire sur sa plateforme de
réalisation des prestations.
Il met en œuvre tous les moyens nécessaires pour garantir l’adaptation et le

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 45 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description
dimensionnement des infrastructures logicielles et matérielles nécessaires au projet
sur la durée de l’accord-cadre, sans frais supplémentaires pour l’administration.

EMT9 Le titulaire s’assure, pour l’ensemble des outils logiciels du système d’informations,
qu’il adopte des principes d’architecture et une démarche qui soient cohérents sur
l’ensemble du SI. A cet effet, il produit des dossiers d’architecture technique communs
et transverses. Il assure en permanence le respect de l’état de l’art en matière
d’architecture technique du SI.

EMT10 Le titulaire s’engage à se conformer à la charte graphique en vigueur sur le SI pour

tout ce qui relève des interfaces utilisateurs et traduites aujourd’hui dans deux
bibliothèques de module, une en vertigo/struts, une autre en vertigo/spring. Il peut être
force de propositions sur l’ergonomie et s’assure de la cohérence globale de cette
ergonomie sur l’ensemble des IHM du SI.

EMT11 Le titulaire s’engage, pour tout nouveau projet, à réaliser des développements en
conformité avec le référentiel RGAA V4.

8.7 EXIGENCES SUR LES VERIFICATIONS ET CONTROLE QUALITE

Référence Description

EV1 Tout produit ou document résultant d’une tâche et faisant l’objet d’une livraison à
l’administration fait l’objet d’un contrôle qualité de la part du titulaire. Ce contrôle est
explicitement intégré à la livraison. Il prévient toute régression fonctionnelle ou
technique.

EV2 Les différents essais conduits sur le système par le titulaire seront tracés de manière à
déterminer la couverture fonctionnelle de ses tests, et des spécifications qui s’y
rapportent.

EV3 La description et le résultat des actions de vérification conduites par le titulaire seront
consignés dans un dossier réservé à cet effet et soumis à la validation par la DNUM
pour acceptation de la livraison.

8.8 EXIGENCES SSI

Référence Description

ESSI1 Le titulaire se conforme aux PSSI applicables et en vigueur sur le SI des outils
numériques du contrôle automatisé. Il y a trois PSSI :
- la PSSI du MI ;
- la PSSI des outils du DCA (Ex SIDCA) ;
- la PSSI de l’ANTAI.
Ces PSSI font l’objet des annexes 6, 7 et 8 du présent marché.

ESSI2 A l’issue d’une analyse de risque au sens EBIOS que serait amené à réaliser la
DNUM sur la plate-forme, le titulaire s’engage à mettre en œuvre toutes les
remédiations prescrites par cette analyse de risque. Le cas échéant, ces actions de
remédiations sont réalisées dans le cadre de prestations de maintenances adaptatives
(sauf en cas où celles-ci s’apparentent à des lacunes de développement et du non-
respect de la part du titulaire des PSSI applicables).
Dans tous les cas, le titulaire s’assure que les actions de remédiations soient faites

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 46 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Référence Description
sans détériorer la capacité de production fonctionnelle.
Les outils déployés actuellement sur le Tenant du cloud PI dits SIDCA sont
homologués au sens EBIOS. Cette homologation doit faire l’objet d’une révision à
chaque intégration de nouveaux applicatifs, soit sur un dossier d’analyse d’écart soit
lors d’une procédure complète d’homologation. La démarche d’homologation retenue
à ce jour sur le cloud PI est une démarche renforcée.
Les outils déployés de la PMVD déployés sur le Tenant DATA-SR du Cloud PI sont en
cours d’homologation à date de rédaction de ce marché.
Le titulaire devra mettre en œuvre toutes les remédiations identifiées résultantes des
commissions d’homologation.

ESSI3 Le titulaire fournit un support et des correctifs de sécurité sur les fournitures objet du
marché. Dans le cas d’une solution embarquant d'autres solutions, les correctifs de
sécurité englobent ceux des solutions embarquées. Les règles de sécurisation de la
solution sont formalisées et fournies au pouvoir adjudicateur.

ESSI4 Le titulaire doit traiter les alertes de sécurité transmises par l’entité responsable ou le
responsable de la sécurité du SI.

8.9 DELAIS DE TRAITEMENT DES ANOMALIES APPLICATIVES

Délais de résolution
NIVEAU (à partir de la
DEFINITION
D’ANOMALIE signalisation de
l’anomalie)
Bloque le fonctionnement de l’application. Toute anomalie
produisant l’altération de données ou qui interdit l’accès
normal aux données (en lecture et/ou en écriture), ou qui Deux (2) jours
rend impossible l’utilisation normale d’une fonction, de ouvrés avec mise en
Bloquante façon rédhibitoire et non contournable par l’administration place d’un
sans intervention du titulaire. contournement sous
(1) un jour ouvré
Est reproductible et le processus de reproduction peut être
décrit.

Interdit la mise en œuvre d’une ou plusieurs fonctionnalités

de l’application, sans qu’il existe de solution de
contournement acceptable par les utilisateurs en matière
Majeure de coût et d’organisation. Cinq (5) jours ouvrés

Est reproductible et le processus de reproduction peut être

décrit

Mise en place d’une

Toute autre anomalie portant sur une ou plusieurs solution de
fonctionnalités sans empêcher leur fonctionnement et ne contournement : dix
produit pas d’altération de données ou des résultats, mais (10) jours ouvrés
rend l’usage des fonctionnalités plus compliquée et
Mineure augmente les temps de traitement.
Ce type d’anomalie implique soit la correction de Mise en œuvre de la
l’anomalie soit un moyen de contournement pouvant être correction de
mis en œuvre par un utilisateur pour parvenir au résultat l’anomalie :
attendu. concertée avec
l’administration

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 47 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

IX. INDICATEURS ET MESURE DE LA QUALITÉ DE SERVICE

Le titulaire est tenu au respect des engagements de qualité de service, basés sur les indicateurs
suivants :

Indicateur Mesure Seuils à respecter

Projet Agile
Vélocité mesurée/vélocité moyenne (ou
Prédictibilité de l’équipe Supérieure à 80%
planifiée)
Alimentation du backlog Nombre d’US complètes et validées Deux (2) sprints complets
Avancement des users Nombre d’US validées/nombre d’US
Supérieur à 85%
stories planifiées
Projet en méthode V (indicateurs à définir)
Cumul en jours de retard de livraison
Respect des délais de
pour tous les livrables d’une même Cible : 0
livraison
commande
Transverse
Nombre de remplacement demandés Pas plus de deux (2)
Respect des
par le ministère pour défaut de remplacements en trois
compétences requises
compétences (3) mois
Nombre de remplacements
d’intervenants à l’initiative du titulaire
Respect de la stabilité Taux de rotation inférieur
sur un (1) an (date anniversaire du
de l’équipe à 15%
marché) pour une personne restant
plus de trois mois
Ne pas dépasser plus de
Qualité des livrables Nombre d’allers-retours sur les livrables
deux (2) allers-retours par
documentaires documentaires
livrable
Nombre de non-conformités Inférieur à 5% des
Non conformité
fonctionnelles lors de la recette métier anomalies
Nombre de patchs passés ou
Sécurité corrections effectuées/nombre de 100%
recommandations par l’administration
Respect à 100% des
Correction des
Durée de correction délais indiqués au §8.9 du
anomalies applicatives
CCTP
Correction en moins de 1
Durée de correction de l’ensemble des semaine
Non régression
régressions Nombre de régressions
maximum par an : 1

Ces indicateurs sont à tenir à jour par le titulaire à minima de manière trimestrielle. Le titulaire
récupère les informations nécessaires par lui-même et peut cependant demander des évolutions de
processus, proposer des adaptations d’outils projets pour cela.

X. DISPOSITIONS COMMUNES À L’ENSEMBLE DES PRESTATIONS

10.1 LIEUX D’EXECUTION ET TELETRAVAIL
Les prestations s’exécutent :
 dans les locaux du titulaire ;
 dans les locaux mis à disposition par l’administration situés en Île-de-France.
Toutes les prestations du marché peuvent être effectuées en télétravail sous réserve :

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 48 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 d’une autorisation préalable de l’administration ;

 d’une définition des modalités pratiques du télétravail concertée entre le titulaire et
l’administration.
Dans le cadre de la prestation P6, le développement s’effectue dans les locaux du titulaire.
Les réunions ou ateliers de travail se déroulent dans des locaux mis à disposition par le titulaire à
proximité de ceux de l’administration (c'est-à-dire des locaux accessibles en transports en commun à
moins de 30 minutes des adresses précitées). Les réunions et ateliers peuvent avoir lieu
occasionnellement dans les locaux de l’administration.
L’infrastructure logicielle et matérielle est fournie par le titulaire, au titre de la prestation P6.
Les serveurs doivent être hébergés en France, et les développements produits devront fonctionner sur
le « cloud » du ministère de l’intérieur qui fonctionne avec OpenStack (HP). En outre, les
développements doivent être effectués en France.
La plateforme de développement à distance du titulaire doit également être accessible à distance par
l’administration.
10.2 HORAIRES D’EXECUTION
La totalité des prestations du marché s’exécute en jours ouvrés de l’administration, en heures ouvrées
(HO), de 08h00 à 18h00.
De façon exceptionnelle, les prestations peuvent également s’exécuter :
 en semaine, en heures non ouvrées (HNO), de 18h00 à 06h00 ;
 le week-end (du vendredi 18h00 au lundi 08h00) ;
 les jours fériés.
Tout atelier de travail ou intervention d’intégration doit être planifié au moins huit (8) jours ouvrés
avant la date de celui-ci, à l’exception de la prestation P1 pour laquelle les réunions sont planifiées
lors du comité de lancement.
10.3 HABILITATION ET ENQUETES D’ACCES
L’exécution des prestations du marché dans le cadre de certains projets peut être subordonnée à
l’obtention préalable par les intervenants du titulaire d’une habilitation dont le niveau est
exclusivement déterminé par l’administration. L’habilitation est délivrée après enquête diligentée par
les services spécialisés du ministère de l’intérieur.
L’habilitation est indépendante de toute procédure d’enquête diligentée par le service compétent du
ministère de l’intérieur et préalable à la délivrance d’une autorisation d’accès aux sites de
l’administration.
Le titulaire est tenu de fournir à l’administration l’ensemble des documents nécessaires à l’instruction
des enquêtes d’habilitation ou d’accès. Le refus de communiquer lesdites pièces constitue un
manquement aux obligations contractuelles du titulaire
10.4 DOSSIER DE PILOTAGE, TABLEAUX DE BORD ET INDICATEURS
Le dossier de pilotage est un document de synthèse à destination de l’administration, établi et
transmis par le titulaire avant chaque comité contractuel sous un délai minimal de deux jours (2)
ouvrés.
Le dossier de pilotage est constitué de tableaux de bord regroupant les indicateurs et les éléments
d’accompagnement nécessaires à leur exploitation (définition des indicateurs, explication modes
d’obtention ou de calculs, explication des valeurs anormales, etc.).
Le dossier de pilotage apporte une claire visibilité sur les thématiques suivantes :
 l’activité et la qualité de la réalisation ;
 les risques (techniques, calendaires, budgétaires, etc.) ;
 les décisions prises en comité ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 49 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 les budgets (prévisionnel, état de la consommation, état de la facturation).

Concernant les indicateurs contractuels de qualité d’activité et de réalisation, la liste non exhaustive
dressée ci-dessous constitue le minimum requis :
 respect des délais et des critères de réception contractuels ;
 conformité et disponibilité de la totalité des résultats et des livrables attendus ;
 maîtrise des délais (prise en compte, réponse aux demandes de service) ;
 garanties de bonnes conditions d’exécution du marché (transparence des résultats de
pilotage, qualité et stabilité des équipes, conformité des processus) ;
 synthèse sur la répartition des demandes ;
 calendrier des actions à venir en rapport aux prochaines livraisons ;
 état d’avancement ou bilan des livraisons effectuées ;
 état des lieux de la production documentaire ;
 ressources humaines mises en place ;
10.5 ÉQUIPE DU TITULAIRE
10.5.1 GENERALITE

Le titulaire s’engage à affecter à l’exécution de l’accord-cadre les personnes ayant les compétences et
l’expérience requises pour l’exécution du présent accord-cadre.
Le titulaire communique à l’administration, à sa demande, les noms, titres et coordonnées
professionnelles des personnes physiques en charge de l’exécution des prestations.
En cas de changement d’un intervenant à l’initiative du titulaire, la période minimale de recouvrement
pendant laquelle le partant communique à son successeur toutes les informations relatives au projet
est fixée à quinze (15) jours.
Si l’administration juge qu’un intervenant est insuffisamment formé à certaines techniques, elle
adresse une demande de mise à niveau au titulaire par tout moyen de communication permettant de
déterminer de façon certaine la date et l’heure de réception. Dans un délai d’un (1) mois, le titulaire est
tenu de procéder à la mise à niveau précitée ou, à défaut, de proposer un nouvel intervenant
présentant le profil demandé.
10.5.2 REGLES DE SENIORITE

Au titre du présent marché, les niveaux de séniorité se définissent conformément aux règles
suivantes :
 junior : moins de trois(3) ans d’expérience dans le domaine d’intervention ;
 confirmé : entre trois (3) ans d’expérience et cinq (5) ans d’expérience dans le domaine
d’intervention ;
 senior : au moins cinq (5) ans d’expérience dans le domaine d’intervention ;
 expert : au moins huit (8) ans d’expérience dans le domaine d’intervention.
10.5.3 NIVEAUX DE SENIORITE IMPOSES

Pour chacune des prestations du marché, le titulaire respecte impérativement les niveaux de séniorité
fixés ci-après selon le principe suivant :
 indication « oui » : profils autorisés ;
 indication « non » : profils non autorisés.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 50 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Prestation / Niveaux
Code UO Junior Confirmé Senior Expert
PRESTATION 1 – INITIALISATION ET PRISE DE CONNAISSANCE
SP1.1 - Initialisation et prise de connaissance – Forfait de base

SP1.1 OUI OUI OUI OUI

SP1.2 - Initialisation et prise de connaissance - Futurs projets
SP1.2_S OUI OUI NON NON

SP1.2_M OUI OUI OUI NON

SP1.2_C NON OUI OUI OUI

PRESTATION 2 – CONCEPTION ET DEVELOPPEMENT DE PROJETS
SP2.1 Conception et développement en mode Agile
SP2.1_S OUI OUI OUI NON
SP2.1_M OUI OUI OUI NON
SP2.1_C OUI OUI OUI NON
SP2.2 Conception et développement en cycle en V
(FEC) OUI OUI OUI OUI
PRESTATION 3 – ASSISTANCE A LA MAITRISE ET LA VALORISATION DE DONNEES (PMVD)
(sur devis) OUI OUI OUI OUI
PRESTATION 4 – TIERCE MAINTENANCE APPLICATIVE
SP4.1. Maintenance adaptative et évolutive
SP4.1.1 OUI OUI OUI NON
SP4.1.2 OUI OUI OUI OUI
SP4.2. Maintenance corrective
SP4.2 S OUI OUI NON NON
SP4.2 M OUI OUI OUI NON
SP4.2 C OUI OUI OUI OUI
PRESTATION 5 – EXPERTISE TECHNIQUE ET EN ARCHITECTURE
5S NON NON OUI OUI
5M NON NON OUI OUI
5C NON NON OUI OUI
PRESTATION 6 – MISE EN PLACE ET MAINTIEN EN CONDITIONS OPERATIONNELLES DE
L'USINE LOGICIELLE
6-1
6-1 OUI OUI OUI NON
6-2 OUI OUI OUI NON
PRESTATION 7 – REVERSIBILITÉ ET TRANSFERT DES ACQUIS
7 OUI OUI OUI NON

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 51 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

10.6 LIVRABLES
10.6.1 GENERALITE

Les livrables sont des documents rédigés en langue française et transmis à l’administration
obligatoirement sous format numérique (généralement Libre Office ou un autre format défini par
l'administration) et, si demandé, sous format papier A4 en deux (2) exemplaires.
La liste des livrables ainsi que les délais de livraison et de vérification se trouve en annexe I du
présent CCTP, dans le document intitulé « découpage des prestations et des livrables » (DPL). Le
titulaire fournit à l’administration les livrables identifiés pour chaque prestation, dans une version
stable.
10.6.2 NORME DE LA DOCUMENTATION

Chaque document émis par le titulaire doit comporter :

 un numéro de version ;
 un état de validité ;
 une date de version ;
 un type de document (compte-rendu de réunion, support de formation, documentation…) ;
 l’identification des modifications apportées.
L’administration peut demander au titulaire la diffusion systématique des documents par messagerie à
l’ensemble des membres de l’équipe projet.
10.6.3 EXIGENCES GENERALES

Le titulaire définit et exécute un processus de contrôle préalable en interne avant toute livraison à
l’administration, permettant de vérifier la satisfaction des exigences requises comme définies ci-
dessous :
 exigences de forme :
o conformité aux modèles types mis en place par l’administration et disponibles dans
des documents de référence, ou, à défaut, des modèles types proposés par le titulaire
dans son offre et validés avec l’administration ;
o conformité avec les spécifications et les objectifs de la maquette ou du prototype ;
o exhaustivité, mise à jour, traçabilité, réutilisabilité du support ;
o exactitude, lisibilité, cohérence intrinsèque et avec les autres productions
documentaires ;
o rédaction, orthographe, grammaire ;
o nommage (règles définies ci-dessus, si non-respect des règles définies conjointement
avec l’administration) ;
o toute(s) autre(s) exigence(s) précisée(s) dans le bon de commande ;
 exigences de fond :
o pertinence des analyses, expertises développées, au regard des enjeux exprimés par
l’administration ;
o en cas de développement, qualité du code fourni, des rapports de tests, des
commentaires et de la documentation associée, ainsi que tout élément indispensable
à la bonne compréhension et au fonctionnement opérationnel de la
fonction/application/service concerné(s) ;
o valeur ajoutée des propositions de scénarii et de solutions faites en résultat des
études commandées par l’administration ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 52 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

o argumentation claire et pertinente des solutions proposées ;

o couverture (fonctionnelle, technique, etc.) de l’ensemble des points et spécifications à
traiter, par rapport à l’expression des besoins de l’administration et à l’état de l’art ;
o démonstration de la prise en compte des spécificités du besoin exprimé par
l’administration par la formalisation de scénarii, solutions, spécifications
personnalisées ;
o toute autre exigence précisée dans le bon de commande.
Pour chaque livrable documentaire, l’administration évalue la qualité de la livraison selon les
exigences ci-dessus et les modalités de réception et vérification précisées dans les documents du
présent accord-cadre. Un manquement à cette nécessité de qualité peut motiver une décision
d’ajournement par l’administration dans les conditions définies au CCAP.
10.7 MODALITES DE VERIFICATION DES PRESTATIONS
Les opérations de vérification des prestations sont effectuées sur la base des livrables qui leur sont
associés, selon les dispositions de l’article X du CCAP
Les délais de vérification par l’administration sont précisés pour chaque prestation à l’annexe I du
présent CCTP (« découpage des prestations et des livrables (DPL) »).
10.8 MODALITES DE COMMANDE DES PRESTATIONS
Les modalités de commande des prestations sont décrites à l’article VII du CCAP.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 53 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XI. PRESTATION 1 (P1) : INITIALISATION ET PRISE DE CONNAISSANCE

Objectifs Cette prestation consiste en :
 la prise de connaissance des environnements organisationnel,
fonctionnel et technique du SI des outils numériques du contrôle
automatisé ;
 la mise en place de l’organisation de travail du titulaire, des
environnements de développement, des outils associés et des
dispositions en matière de qualité et de sécurité ;
 la mise en place de son organisation de pilotage des prestations et des
outils de reporting auprès de l’administration ;
 la mobilisation et la montée en compétences des équipes du titulaire.

Prérequis  ensemble des documentations existantes sur le SI ;

fournis par
l’administration  liste des incidents identifiés et en cours ;
 indicateurs de performance du parc applicatif actuel ;
 description et fourniture de l’ensemble des composants techniques du
parc applicatif à maintenir (en vue de l’installation par le titulaire sur son
environnement propre), et documentations associées.

Modalités de Les modalités de commande sont précisées dans le CCAP.

commande

Activités et  prise de connaissance par le titulaire :

tâches à réaliser
o du contexte organisationnel du ministère de l’intérieur ;
o du contexte fonctionnel et technique ;
o du SI des outils numériques du contrôle automatisé ainsi que de
l’ensemble de ses modules techniques.
 montée en compétence des équipes et le transfert de connaissances, par
des présentations assurées conjointement par le titulaire sortant et
l’administration, et portant sur :
o le contenu fonctionnel et technique du SI des outils numériques
du contrôle automatisé ;
o l’architecture technique et détaillée du système ;
o les composants techniques du SI (architecture technique, outils,
progiciels, codes sources, etc.) ;
o prise en main des développements sous contrôle du titulaire
sortant.
 la mise en œuvre de l’organisation projet, et notamment :
o l’organisation pour la maintenance corrective, adaptative et
évolutive
o l’organisation pour le développement de projets logiciels :
 en AGILE avec des processus propres au développement
Agile ;
 en V ;
o formalisation du plan d’assurance qualité (PAQ) et du plan
d’assurance sécurité (PAS) et du plan de management projet

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 54 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

(PMP) associés au marché ;

o la validation de la priorité des backlogs avec les PO métier ;
o la définition du backlog produit au moment du lancement du projet
ainsi que les spécifications des fonctions à développer dans le
premier sprint.
 l’élaboration d’un état des lieux des systèmes, matériels et logiciels
repris permettant de constituer les éléments permettant de fournir à
l’administration et au titulaire les moyens de constater de l’état d’une
application;
 la mise en place des outils de reporting ;
 le recensement de l’ensemble de la documentation avec mise en
évidence du niveau de documentation (excellent, très bon, moyen, faible,
insuffisant ou inexistant)
 la réalisation de la bascule de responsabilité.

Délais Forfait d’initialisation de base :

La durée de réalisation de cette prestation pour le lancement du marché est de 60
jours ouvrés maximum à compter de la notification du bon de commande.
Néanmoins, le titulaire doit être sensibilisé sur le fait que la mise en place de ses
plates-formes de développement et de maintenance doit être opérationnelle dès le
premier mois suivant la notification du marché.
La durée de 60 jours vaut surtout pour la montée en connaissance de ces équipes
dans le contexte technique du SI et organisationnel de l’administration.
Les PAQ, PMP et PAS sont à fournir dans un délai d’un mois maximum à compter
du démarrage de la prestation.
UO d’initialisation et prise de connaissance pour les projets futurs :
La charge estimée de réalisation de la prestation pour les autres projets est fixée
dans le tableau infra :

Référence UO P1 S P1 M P1 C
Niveau de
complexité du Simple Moyen Complexe
projet
Charge estimée
10 20 30
en j/h

Livrables A l’issue de la prestation, le titulaire remet à l’administration les livrables figurants

dans l’annexe 1 du CCTP intitulée « Découpage des prestations et des
livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le juge
utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 55 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XII. PRESTATION 2 (P2) : CONCEPTION ET DEVELOPPEMENT DE PROJETS

Cette prestation est composée de deux sous-prestations :

 SP2.1 Conception et développement de projets en mode Agile ;
 SP2.2 Conception et développement de projets en cycle en V.

Objectifs La présente prestation a pour objet la conception et le développement de projets,

de nouvelles fonctionnalités en complément du SI existant en mode Agile ou en
cycle en V comme exposé au § « VII - DÉMARCHE DE CONCEPTION,
DÉVELOPPEMENT ».
La démarche qui prévaut pour la réalisation de cette prestation est exposée aux §
7.3 « Étape de conception technique et de développement agile » et aux § 7.4
« Étape de conception et de développement en cycle en V ».

Prérequis  description du ou des besoins métiers à couvrir ;

fournis par
l’administration  liste des interlocuteurs concernés de l’administration ;
 backlog priorisé (si nécessaire) ;
 spécifications fonctionnelles générales (SFG) si existantes, avec maquette
(à co-construire sinon).

Modalités de Les modalités de commande sont précisées dans le CCAP.

commande

Activités et Conformément à la démarche exposée ci-avant au § « VII - DÉMARCHE DE

tâches à CONCEPTION, DÉVELOPPEMENT », le titulaire doit :
réaliser
Activités communes à la démarche Agile ou en cycle en V
 procéder, avec le DCA, au cadrage du projet : définition du planning de la
version et du périmètre et dates de livraisons des éventuelles versions
intermédiaires ;
 concevoir, si nécessaire, les outils de reprise de données, procéder à la
reprise de ces données et effectuer les tests techniques adéquats ;
 faire la revue des maquettes avec le DCA ;
 procéder à la livraison sur l’environnement d’intégration défini par le
ministère ;
 rédiger et mettre à jour les contrats d’interfaces et swagger associés ;
 mettre à jour la documentation du produit : dossier d’architecture général
(DAG), dossier architecture applicatif (DAA), dossier architecture technique
(DAT), dossier fonctionnel, dossier d’exploitation, guide utilisateur, dossier
des interfaces, dossier des données, SSI, etc. ;
 en cas de changement de l’équipe en charge du développement et de la
maintenance d’un composant, soit pendant son développement soit après
sa mise en service, assurer le transfert de compétences à destination de la
nouvelle équipe ;
 rédiger et mettre à jour les spécifications techniques détaillées de chaque
version de l’application livrée ;
 assurer les correctifs des anomalies constatées lors de phases de VA et
de VSR.
Le ministère ne peut être tenu responsable des éventuels écarts de
fonctionnement du produit entre l’environnement de production et ceux de

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 56 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

développement et de test.
Les modalités de VA et VSR sont précisées au § 7.6 « Étape de vérification (VA,
VSR) ». Les correctifs des anomalies durant ces phases sont intégrés à la version
sans surcoût.
La typologie des anomalies et leur délai de traitement figurent au § 8.9 « Délais de
traitement des anomalies applicatives » du présent CCTP.
Tant que la décision de réception faisant suite aux vérifications n’est pas
prononcée pour la version concernée, le titulaire prend en charge l’ensemble des
opérations de correction nécessaires à la remise en état de fonctionnement optimal
de l’application.
Activités liées uniquement à la démarche en V :
 rédiger les spécifications techniques détaillées ;
 procéder aux développements, tests unitaires, packaging, documentation
associée ;
 effectuer les tests de bon fonctionnement de bout en bout au niveau
fonctionnel conformément aux spécifications générales ;
 effectuer les tests de bon fonctionnement de bout en bout au niveau
technique (absence de génération d’erreur ou d’exception) ;
o tests de qualité du code ;
o tests de non-régression fonctionnelle et technique ;
o tests de résilience ;
o d’intégration technique.
Activités liées uniquement à la démarche Agile
 rédiger les spécifications techniques détaillées des fonctions et des
interfaces contenues dans les sprints futurs ;
 définir avec le PO et le CoPO les US ;
 rédiger les US ;
 repositionner un calendrier clair et engageant sur les livraisons de la
version ;
 planifier les itérations avec le CoPO et le PO (revue des stories, définition
des critères d’acceptation, estimation en story points, validation du contenu
de l’itération selon la vélocité connue ou la capacité calculée). L’équipe
doit inclure dans chaque itération des corrections de bugs et la réduction
de la dette technique et sécuritaire ;
 maintenir et faire vivre le backlog de l’équipe. Le titulaire est responsable
notamment de son alimentation en US. Pour maintenir un bon flux de US,
il s’assure que les backlogs des équipes contiennent en moyenne
l’équivalent de deux itérations ;
 participer activement à la préparation et au déroulement des pockers
plannings du fait de sa responsabilité sur le backlog ;
 enrichir si besoin les critères d’acceptation et les tests liés des US définis
par le CoPO ;
 dialoguer avec l’expert tech lead de son équipe sur les solutions
envisagées, la mise à jour de la base de données… ;
 développer et tester les stories ainsi définies de l’itération, y compris les
interfaces (si applicable). Les tests incluent a minima :
o les tests de bon fonctionnement de bout en bout au niveau

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 57 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

fonctionnel (conformité avec les critères d’acceptation des « user

stories ») ;
o les tests de bon fonctionnement de bout en bout au niveau
technique (absence de génération d’erreur ou d’exception) ;
 tests de qualité du code ;
 tests de non-régression fonctionnelle et technique ;
 tests de résilience ;
 d’intégration technique.
 procéder en fin d’itération à la démonstration du système intégrant tous les
composants et fonctionnalités développées ;
 procéder aux rituels quotidiens ;
 suivre la vélocité de l’équipe et préparer un reporting pour l’administration
lors des comités de suivi et pour le PM et calculer la part des anomalies du
sprint ;
 procéder à la rétrospective de l’itération ;
 participer à la préparation des rituels du programme.
Toutes les anomalies identifiées sur un « sprint » courant doivent être corrigées
dans le « sprint » suivant sans surcout.

Durée/Charge SP2.1 - En mode Agile :

de la prestation
La méthode de dimensionnement est basée sur des itérations avec trois (3)
niveaux de complexité (simple, moyen, complexe), complétées le cas échéant pas
des unités d’œuvre complémentaires telles que décrites ci-dessous.
SP2.2 En cycle en V :
La méthode de dimensionnement, basée sur une FEC, est décrite ci-dessous.

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les livrables

figurants dans l’annexe 1 du CCTP intitulée « Découpage des prestations et des
livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le juge
utile.

Méthode de dimensionnement d’un projet en mode Agile

En mode agile, le dimensionnement d’un projet est basé sur des itérations avec les niveaux de
complexité suivante :

NIVEAU DE
DEFINITION DU NIVEAU DE COMPLEXITÉ
COMPLEXITE

Sprint Simple de 2 Un (1) Sprint nécessitant la mobilisation d’un (1) développeur/ Tech Lead sénior +
semaines deux (2) développeurs confirmés

Sprint Moyen de 2 Un (1) Sprint nécessitant la mobilisation d’un (1) développeur/ Tech Lead sénior +
semaines deux (2) développeurs confirmés + deux (2) développeurs juniors

Sprint Complexe Un (1) Sprint nécessitant la mobilisation de deux (2) développeurs/ Tech Lead
de 2 semaines séniors + trois (3) développeurs confirmés + trois (3) développeurs juniors

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 58 | 76
CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 59 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

A ces Sprint, peuvent être adossées les unités d’œuvre suivantes :

UO DEFINITION DU NIVEAU DE COMPLEXITÉ

Simple 5 j.h d'un développeur de profil Junior

Développeur Moyen 5 j.h d'un développeur de profil Confirmé

Complexe 5 j.h d'un développeur de profil Sénior

Simple 5 j.h d'un tech lead de profil Junior

Teach lead Moyen 5 j.h d'un tech lead de profil Confirmé

Complexe 5 j.h d'un tech lead de profil Sénior

Simple 5 j.h d'un proxy po de profil Junior

proxy PO Moyen 5 j.h d'un proxy po de profil Confirmé

Complexe 5 j.h d'un proxy po de profil Sénior

Simple 5 j.h d'un scrum master de profil Junior

Scrum master Moyen 5 j.h d'un scrum master de profil Confirmé

Complexe 5 j.h d'un scrum master de profil Sénior

Simple 5 j.h d'un consultant test de profil Junior

Ingénieur tests et
Moyen 5 j.h d'un consultant test de profil Confirmé
recette

Complexe 5 j.h d'un consultant test de profil Sénior

Simple 5 j.h d'un consultant test de profil Junior

Technicien tests et
Moyen 5 j.h d'un consultant test de profil Confirmé
recette

Complexe 5 j.h d'un consultant test de profil Sénior

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 60 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Méthode de dimensionnement d’un projet en cycle en V

A partir de l’expression de besoins, chaque version est dimensionnée sur la base d’une formule
d’évaluation des coûts (FEC) fondée sur combinaison d’éléments unitaires dont les coûts sont
exposés dans l’annexe financière :
 IHM (Interface Homme Machine) ;
 Batch ou traitement métier (traitement côté serveur, sans interaction avec l’IHM) ;
 Interface externe ;
 Objet de la base de données.
Une fois le dimensionnement réalisé, l’administration et le titulaire s’accordent sur le dimensionnement
de l’équipe lors de l’étape de cadrage. Ce dimensionnement évolue tout au long du projet en fonction
des besoins à chaque étape
Les éléments unitaires font l’objet de trois (3) types de complexité possibles :
 simple (S) ;
 moyen (M) ;
 complexe (C).
Ces évolutions fonctionnelles et techniques sont décomposées dans les tableaux suivants, pour
chacune des différentes catégories d’évolutions.
IHM et interface de restitution sans les outils cartographiques du SI DCA
On entend par IHM, les interfaces de présentation des utilisateurs du SI. Ces interfaces étant
indépendantes des différents traitements métier effectué par le SI ou par ses satellites.
Une même IHM ou restitution utilisée ou adaptée pour un autre module du SI ne pourra être comptée
qu’une seule fois.

Complexité Fonction

Modification de la présentation d’une IHM existante et / ou ajout de nouveaux champs

S sans règle de gestion métier (uniquement des règles de gestion sur l’IHM)
(libellé, champs, ordre de présentation, autres)

Ajout de nouveaux champs d’une IHM existante avec règle de gestion métier
M
(libellé, champs, autres)

C-sansCarto Création d’une nouvelle IHM avec 15 champs au maximum

IHM et interface de restitution avec les outils cartographiques du SI DCA

Complexité Fonction

Modification de la présentation d’une IHM existante et / ou ajout de nouveaux champs

sans règle de gestion métier (uniquement des règles de gestion sur l’IHM) avec
S-Carto
intégration aux outils cartographiques du DCA (libellé, champs, ordre de présentation,
autres)

Ajout de nouveaux champs d’une IHM existante avec règle de gestion métier avec
M-Carto intégration aux outils cartographiques du DCA
(libellé, champs, autres)

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 61 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Création d’une nouvelle IHM avec 15 champs au maximum avec une nouvelle
C-Carto
intégration aux outils cartographiques du DCA

Batch ou Traitement métier

Ils concernent l’ensemble des règles de gestion à réaliser. Leur complexité est appréciée en fonction
du nombre de règle de gestion impactée ou en fonction de la nature de la règle.
Un même batch ou traitement métier utilisé ou adapté pour un autre module du SI ne pourra être
compté qu’une seule fois.

Complexité Nombre de règles de gestion Nature de la règle

S de 1 à 8 Règle de gestion / 1 donnée

M de 9 à 15 Règle de gestion / n données

C de 15 à 22 Règle de gestions / modification du séquencement

Interface externe
La complexité des interfaces externes est appréciée en fonction du nombre de règle de gestion
impactée ou en fonction du type d’échange ou d’interopérabilité.
Une même interface externe utilisée ou adaptée pour un autre type de connexion du SI par exemple,
interface externe par webservice synchrone et asynchrone) ne pourra être comptée qu’une seule fois.

Complexité Nombre de règles de gestion Autres

un (1) échange, sans rupture de la logique de

S de 1 à 8
traitement existante

n échanges, formatages simples, formatages

M de 9 à 15
complexes ou nombreux

n échanges, multi/site national, protocole de

C de 15 à 20 communication, modification architecture
programme

Éléments de gestion de données (structure des données)

La complexité des éléments de gestion de données est appréciée en fonction du type d’accès aux
tables ou aux fichiers et en fonction de la notion de migration de données ou de création des objets.
Une même colonne ou table ajoutée ou supprimée dans plusieurs bases de données ne pourra être
comptée qu’une seule fois.

Complexité Type d’accès en table ou aux fichiers

S Ajout, modification ou suppression d’une colonne d’une table SANS migration de données

M Ajout, modification ou suppression d’une colonne d’une table AVEC migration de données

C-sans_Mig Ajout, modification ou suppression d’une table (jusqu’à 25 colonnes) sans migration de données

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 62 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

C-avec_Mig Ajout, modification ou suppression d’une table (jusqu’à 25 colonnes) avec migration de données

Cette logique de décomposition en éléments unitaires s’applique également pour les prestations de
maintenance adaptative et évolutive (cf. 14.114.1 )
La décomposition d’un projet en cycle en V, suit cette logique.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 63 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XIII.PRESTATION 3 (P3) : ASSISTANCE A LA MAITRISE ET A LA VALORISATION DE DONNEES

-PMVD

Objectifs Le SI se complète par une plate-forme dédiée à la maîtrise et la valorisation

de données (PMVD).
A l’appui de cette plate-forme, l’objet de la prestation est de procéder :
- zone de stockage à froid des données brutes :
o à l’ajout ou l’évolution d’un flux d’alimentation des données
de manière automatique (flux SFTP, API Rest, JSON,
etc.) et à leur gestion dans la zone de stockage à froid de la
PM ;
o à l’ajout manuel de données ;
- mise à disposition des données pour traitement :
o à la spécification et mise en place ou évolution d’un
DATAMART permettant de mettre en forme les données ;
o à la réalisation ou à l’évolution d’applications analytiques
(POC ou industrialisation) à des fins de restitutions
statistiques (données, graphiques, cartographique) ou
décisionnelles par exemple.
Cette prestation nécessite à la fois de l’expertise en manipulation de
données non structurées et la capacité de réaliser des développements
autour des outils suivants de restitution.
Les outils utilisés à cet effet sont :
- Grafana ;
- ElasticSearch ;
- Tableau Software ;
- JupyterLab ;
- Hadoop ;
- DSS ;
- Et un ETL pour le chargement et le traitement de la donnée.

Prérequis fournis par  description du ou des besoins métiers à couvrir ;

l’administration
 liste des interlocuteurs concernés de l’administration ;
 plate-forme de données mise à disposition ;
 mise à disposition des outils de la PMVD.

Modalités de Cette prestation est une prestation sur devis dans les conditions fixées au
commande CCAP.

Activités et tâches à Le titulaire réalise les actions suivantes (liste non exhaustive) :
réaliser
 études techniques de solutions de valorisation de la donnée ;
 développement de prototypes ;
 conception et développement d’outils ;
 définition d’indicateurs ;
 paramétrage d’outils d’interrogation de bases de données non
structurées ;
 rédaction des documentations associées ;
 assistance à la généralisation et à l’utilisation des outils
développés ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 64 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

 correction en cas d’anomalie.

Durée de la La durée de la prestation est fixée dans le devis auquel donne lieu la
prestation prestation.

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les

livrables figurants dans l’annexe 1 du CCTP intitulée « Découpage des
prestations et des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 65 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XIV. PRESTATION 4 (P4) : TIERCE MAINTENANCE APPLICATIVE

Cette prestation est composée de deux sous-prestations :
 SP 4.1 Maintenance adaptative et évolutive ;
 SP 4.2 Maintenance corrective et support.
14.1 SP4.1 MAINTENANCE ADAPTIVE ET EVOLUTIVE

Objectifs Maintenance évolutive : faire évoluer le SI, afin d’intégrer de nouvelles

fonctionnalités ou faire évoluer une fonctionnalité déjà en production, en
améliorer le fonctionnement, prendre en compte de nouvelles dispositions
législatives et/ou réglementaires ou faire face à de nouvelles exigences
fonctionnelles ou techniques.
Maintenance adaptative : adapter techniquement le parc applicatif lié au SI
suite à toute évolution du socle technique sur lequel il s’exécute (changement
de technologie, de versions de système d’exploitation, de versions de logiciels
tiers, de matériels, etc.), les besoins fonctionnels ou métiers restant inchangés.

Prérequis fournis Pour la maintenance évolutive : spécifications générales et fonctionnelles des

par l’administration évolutions souhaitées.
Pour la maintenance adaptative : versions des briques techniques composant
le socle d’exécution des composants du SI à maintenir.

Modalités de La sous-prestation SP4.1 se caractérise par deux modalités de commandes :

commande
 pour des petites évolutions / adaptations sur la base d’une UO
spécifique « petite évolution/adaptation » déclenchée par l’émission
d’un bon de commande. Une petite évolution - adaptation se
caractérise par un besoin urgent et une charge de travail de la part du
titulaire ne dépassant pas deux (2) jours homme d'un profil
développeur ;
 évolution du paramétrage technique des outils : au titre de cette action,
le titulaire assure des actions de paramétrage technique. Ces actions
de paramétrage se réalisent en dehors d’un cycle de développement
Agile et sont déclenchées par une fiche d’expression de besoin (FEB -
voir ci-dessous). A titre d’exemples, il peut s’agir des outils GLPI, GED
CA, ITEROP, etc. ;
 pour des évolutions / adaptations et des actions de maintenance
perfective n’entrant pas dans la catégorie ci-dessus, par émission
d’une FEB.
Le déclenchement d’une action de maintenance adaptative ou les évolutions du
paramétrage technique des outils peuvent être sollicités par l’administration ou
par le titulaire (sous réserve d’acceptation par l’administration).
L’administration transmet au titulaire une expression de besoin technique (mini
cahier des charges). Ce dernier dispose d’un délai maximal de dix (10) jours
ouvrés pour transmettre à l’administration une proposition technico-financière.
Le prix de la prestation est calculé sur la base de la formule d’évaluation des
coûts objet de l’annexe 2 à l’acte d’engagement (annexe financière). La durée
de validité de la proposition technico-financière est limitée à trois mois.
Si la proposition du titulaire recueille l’agrément de l’administration, celle-ci
émet un bon de commande correspondant à l’acte de maintenance est ferme et
définitive.
Le déclenchement d’une action de maintenance évolutive ne peut être sollicité
que par l’administration.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 66 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

Le délai de réalisation est fixé dans le bon de commande.

Activités et tâches Les évolutions / adaptations concernées par la prestation se caractérisent soit
à réaliser par des projets de développement classiques, soit par de petites évolutions /
adaptations selon l’importance du périmètre qu’elles adressent.
Pour chaque évolution, le titulaire adopte une démarche de développement
unique permettant de réaliser les actions suivantes :
 spécifications techniques détaillées ;
 conception ;
 développement ;
 intégration des composants et tests d’intégration ;
 réalisation des tests unitaires ;
 tests de non régression ;
 packaging et livraison des composants ;
 mise à jour de la documentation inhérente (spécifications, architecture
technique, architecture applicative, installation) ;
 assistance à la VA (Vérification d'Aptitude) ;
 assistance à la VSR (Vérification en Service Régulier) ;
 pilotage de chaque projet d’adaptation/évolution ;
 suivi de la sous-prestation.
Pour les petites évolutions / adaptations ou le paramétrage technique des
outils :
Les petites évolutions/adaptations ou le paramétrage des outils ne constituent
pas usuellement des évolutions critiques ou majeures du système. Elles font
l’objet d’une démarche adaptée voire d’une livraison spécifique (i.e.
développement de type « rustine ») et peuvent être livrées exceptionnellement
à l’occasion d’une version planifiée du système.
Pour assurer leur réactivité de réalisation, celles-ci s’inscrivent dans une
démarche projet simplifiée par rapport à une démarche de développement
traditionnelle. Ainsi par exemple le titulaire devra assurer au minimum la
non-régression du système lors de la réalisation des petites évolutions et
adaptations mais celles-ci pourront donner lieu à une VA d’une (1) semaine et
une VSR de deux (2) semaines à discrétion de l’administration.

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les livrables

figurants dans l’annexe 1 du CCTP intitulée « Découpage des prestations et
des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 67 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

14.2 SP4.2 MAINTENANCE CORRECTIVE

Objectifs La maintenance corrective débute à l’issue de la période de garantie

déclenchée par l’admission des versions du SI mises en production (garantie
d’un an conformément aux dispositions du CCAP).
La maintenance corrective comprend :
- d’une part, la mise à disposition d’une cellule de support technique ;
- d’autre part, en cas d’incident affectant l’application ou le logiciel ayant des
conséquences sur le fonctionnement opérationnel du système, la correction
du/des programmes et/ou des données, ou l’indication, le cas échéant,
d’une solution de contournement permettant le redémarrage de l’élément
défaillant.
Le système est considéré comme remis en état, dès lors que son
fonctionnement normal est rétabli.
Cette procédure doit inclure la mise à jour de tous les livrables concernés par la
correction.
Dans le cadre du SI, une AMOA assure le premier niveau (N1) du support et le
titulaire les niveaux 2 et 3 relatifs à l’analyse, la qualification et la correction et
résolution des anomalies.
Pour le niveau 1, le support AMOA gère un outil de ticketing spécifique aux
utilisateurs (GLPI). Quand ils ne savent pas résoudre le problème, ils remontent
au niveau N2 qui est capable de faire une meilleure analyse et de déclencher
un correctif. Quand c’est une évolution, c’est du niveau N3.

Prérequis fournis Description de l’incident (au sein de la solution en ligne mise en place par le
par l’administration projet).
Description du scénario de déclenchement de l’incident.

Modalités de Cette sous-prestation est déclenchée par émission d’un bon de commande
commande selon les unités d’œuvre du marché.

Activités et tâches La prestation se réalise pendant les jours et heures ouvrés.

à réaliser
Le titulaire s’appuie sur un outil mis en œuvre et hébergé par l’administration ou
son AMOA pour gérer le ticketing d’incidents. Le titulaire en administre les
usages en le paramétrant pour réaliser les opérations de maintenance
corrective.
Le support technique peut être sollicité par les agents du ministère habilités à
signaler les incidents. Ces agents déterminent la qualification de l’incident lors
de la demande d’intervention.
Le titulaire réalise les actions suivantes :
 analyse de l’incident :
- réalisation d’un premier diagnostic sur l’origine de l’incident et
sa qualification ;
- vérification des paramètres du système et confirmer le défaut
logiciel ;
- réalisation d’une analyse approfondie des problèmes logiciels
rapportés par le second niveau d’assistance ;
- proposition d’une solution de contournement si l’anomalie ne
peut pas être résolue immédiatement ;
- proposition d’une façon de résoudre l’anomalie ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 68 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

- reporte dans l’outil de suivi de l’analyse de l’anomalie et

mentionne la date de résolution effective en homologation et en
production ;
- informe les acteurs concernés par l’anomalie.
 génération des patchs et des versions :
- correction de l’anomalie (développement, correction de
programme, etc.) ;
- réalisation des tests (y compris tests de non régression).
 mise à jour de la documentation :
- mise à jour de la documentation impactée suite aux corrections
effectuées ;
- reporte toute modification dans l’outil de suivi et notamment les
dates de livraison effectives.
 suivi de la sous-prestation :
- production des états récapitulatifs mensuels, trimestriels et
annuels des opérations de maintenance corrective ;
- préparation et participation aux comités de suivi.
 surveillance des applications :
- vérification que le système d’information des outils numériques
du contrôle automatisé réponde, en matière de performance,
aux exigences prévues ;
- réalisation d’un suivi et d’un reporting.
 assure le suivi périodique et à chaque étape (au minimum les étapes
suivantes : prise en compte, en cours de traitement, résolue) du
traitement de la demande via l’outil en ligne mis en place par ses soins.
Délais et modalités Les commandes sont passées après établissement d’un devis par le titulaire
de commande sur demande de l’administration pour un stock d’anomalies déjà déclarées (lot
de tickets).
Dans son devis le titulaire qualifie les anomalies à traiter suivant les unités
d’œuvres (UO) décrites ci-après et réalise si nécessaire une étude d’impact.
Cette qualification fera l’objet d’une validation de l’administration.

Référence UO SP4.2 S SP4.2 M SP4.2 C

Niveau de
Simple Moyen Complexe
complexité
Inférieure à 2
Charge j/h de
jours / homme De 2 j/h à 5 j /h De 6 j/h à 9 j/h
correction
(j/h)

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les livrables

figurants dans l’annexe 1 du CCTP intitulée « Découpage des prestations et
des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 69 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XV. PRESTATION 5 (P5) : EXPERTISE TECHNIQUE ET EN ARCHITECTURE

Objectifs Cette prestation a pour objectif la réalisation d’expertises techniques et en

architecture pour le compte de l’administration sur des sujets liés au SI des
outils numériques du contrôle automatisé et son écosystème technique et des
sujets liés à la PMVD.

Prérequis fournis L’administration transmet au titulaire un cahier des charges précisant

par notamment :
l’administration
 le lieu d’exécution de la prestation ;
 le domaine d’expertise ;
 le périmètre de l’intervention et les livrables attendus ;
 le planning de la prestation.

Modalités de Cette prestation donne lieu à l’émission de bons de commande sur la base
commande d’unités d’œuvre.

Activités et tâches Le titulaire réalise des expertises et produit la documentation afférente.

à réaliser
Les prestations susceptibles d’être réalisées sont :
- comparaison de solutions ;
- validation de solution ;
- rédaction et mise à jour de la documentation de l’architecture ;
- des études de dimensionnement ;
- analyse des conditions d’intégration d’application tierce ;
- étude globale d’impact.
Les expertises peuvent concerner les sujets suivants :
 Sujet ayant trait à l’informatique et au SI :
o data science ;
o benchmarking de solutions ;
o SSI ;
o big data ;
o système d’information géographique ;
o protocole de sécurisation ;
o framework : Spring boot, AngularJS2, vertigo strust pour la
TMA ;
o langages: TypeScript, Java, Javascript, XSD, XML ;
o analytics : elasticSearch / Hadoop / Kibana / Logstash ;
o systèmes d'informations géographiques (SIG) ;
o mobilité ;
o systèmes décisionnels - entrepôts ;
o architecture SOA ;
o réseaux LAN et WAN ;
o serveurs et systèmes d’exploitation ;
o stockage et sauvegarde ;
o bases de données ; Postgresql ;

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 70 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

o interfaces d’échange ;
o architecture technique ;
o briques de sécurité ;
o exploitation.
 Sujets liés à l’ergonomie :
o l’expertise d’ergonomie vise à formaliser le contenu, la
présentation et l’enchaînement des écrans ;
o le titulaire élabore les règles d'ergonomie avec les acteurs du
projet. Il veille à proposer une interface graphique selon l’état
de l’art des développements d’application web en proposant
notamment un site web adaptatif (responsive web design)
respectant le cadre du référentiel RGAA 4. L’ergonomie de
l’application doit être conforme à la charte internet de l’État et
se baser sur l’ergonomie des sites des juridictions
administratives en particulier celle du Conseil d’État, qui lui est
fournie par l’administration ;
 Tout autre domaine de compétence de la MOE.
La prestation s’exécute dans les locaux de l’administration ou du titulaire.
Le titulaire est responsable de la mise à jour du référentiel architecture
complet suite à ses études, si celles-ci ont un impact sur ce référentiel (DAT,
DAG, …).

Délais L’administration distingue les trois (3) niveaux de complexité suivants :

Référence UO P5 S P5 M P5 C
Niveau de
Simple Moyen Complexe
complexité
Charge estimée
1 5 10
en j/h

Livrables A l’issue de la prestation, le titulaire remet à l’administration les livrables

figurants dans l’annexe 1 du CCTP intitulée « Découpage des prestations et
des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 71 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XVI. PRESTATION 6 (P6) : MISE EN PLACE ET MAINTIEN EN CONDITION

OPERATIONNELLE DE L’USINE LOGICIELLE – GESTION ET HEBERGEMENT DE
L’OUTILLAGE DU SI
Cette prestation est composée des deux sous-prestations suivantes :

sous-prestation
Mise en place et configuration initiale de l’usine logicielle
SP6.1

sous-prestation Mise à disposition et maintien en condition opérationnelle des infrastructures

SP6.2 logicielles et matérielles

Objectifs Le plateau de développement se situe sur le site du titulaire. À ce titre, le

titulaire met en place et configure l’usine logicielle sur son site.
L’environnement technique du système d’information des outils numériques du
contrôle automatisé est très dense quant à ses composantes techniques et son
socle d’ingénierie (la forge applicative).
Actuellement, l'environnement de développement mis en place dans le CLOUD
de la DNUM n'est pas utilisé, la livraison dans les environnements DNUM se
fait par des packages compilés et déposés dans l'environnement d'intégration.
L'outil de distribution déploie les versions sur les autres environnements en
fonction du besoin (recette, formation, préproduction, production,...) décrits en
annexe. Ce fonctionnement amène le DCA à réaliser une double recette pour
éviter le packaging CLOUD d'une version pour chaque correctif :
 une première recette sur l'usine logicielle de l'AMOE, puis quand la
version est satisfaisante elle est packagée et déployée dans
l'environnement recette du CLOUD,
 puis une nouvelle recette est réalisée sur le CLOUD.
Ce fonctionnement n'est pas satisfaisant car les recettes sont déroulées deux
fois du fait d'un déploiement complexe dans le CLOUD.
La sous-prestation 6.1, nécessite du titulaire qu’il mène une étude sur l'usine
logicielle et la forge du DCA pour optimiser les processus de déploiement, de
tests et de recette reposant sur les hypothèses suivantes :
 il faut considérer que la forge actuelle pour le projet est opérationnelle
uniquement sur les éléments décrits ci-dessus et en annexe,
 la mise en œuvre dans le CLOUD sera réalisée par le titulaire de
l'exploitation et intégration,
 l'accès à la forge n'est pas ouverte sur internet mais uniquement via
des postes sécurisés (SPAN).
Sur la base des conclusions de cette étude et de sa validation par
l’administration le titulaire met en place sa plate-forme de développement et de
maintenance intégrant l’ensemble des outils nécessaires à ce SI complexe.
Ces outils se composent :
- du socle d’ingénierie nécessaire au développement (y compris si
besoin les plateformes) ;
- des outils de travail collaboratifs avec l’ensemble des parties prenantes
du SI. Pour les outils de gestion de projet collaboratifs, l’administration
pourra fournir les licences et le titulaire les installera et les hébergera
dans ses propres environnements.
La présente prestation concerne l’installation de cette plate-forme, son maintien
en condition opérationnelle au cours du marché. Cette plateforme et ses

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 72 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

interfaces avec la plateforme du ministère de l’intérieur permettent de ne pas

avoir de nouvelles anomalies sur les plateformes de production, et de
reproduire les anomalies détectées en production le cas échéant.
Elle couvre également les besoins de compatibilité de la plate-forme du titulaire
avec celle de l’administration. Pour précision les développements réalisés sur
l’environnement du titulaire doivent s’exécuter dans les mêmes conditions et
sans régression sur la plate-forme de l’administration. Le titulaire assure la
bonne transmission dans les environnements de l’administration (forge SI DCA)
des livrables, packages et autres éléments techniques nécessaires à la bonne
exécution des applications et modules développés.
Par ailleurs et pour rappel, il est demandé que les serveurs d’hébergement
soient localisés en France métropolitaine.
Le cas échéant et au cours de l’exécution du marché, l’administration pourra ré-
internaliser la plate-forme de développement, sans que cela n’engendre de
coût additionnel.
 la description de l’ensemble des composantes de l’ingénierie
Prérequis fournis
applicative nécessaire aux développements et à la maintenance du SI ;
par l’administration
 la liste des outils à héberger par le titulaire ;
 les modalités d’interconnexion en mode sécurisé à l’environnement de
l’administration.

Modalités de Cette prestation donne lieu à l’émission de bons de commande conformément

commande aux dispositions du CCAP.

Activités et tâches Sous-prestation 6.1 :

à réaliser
 réunion de vérification des outils constituant l’usine logicielle avec les
équipes techniques du ministère de l’intérieur ;
 étude et expertise sur l'usine logicielle et la forge du DCA pour
optimiser les processus de déploiement, de tests et de recette
(conformément aux hypothèses énoncées plus haut) ;
 acquisition des solutions logicielles requises si non disponibles chez le
titulaire ;
 installation de la plate-forme et des outils ;
 paramétrage des outils ;
 interconnexion et tests d’interconnexion avec les environnements de la
DNUM ;
 administration et supervision de la plate-forme ;
 mise en place et hébergement de la plateforme de développement du
titulaire et reprise de l’ensemble des composants techniques du SI
(packages, code source, etc.) ainsi que les raccordements nécessaires
avec les sites de l’administration et la mise en place des interfaces
avec les SI externes (IGN, Qualif SI ANTAI, etc.) ;
 mise en place et hébergement de tout autre environnement permettant
de faciliter les recettes menées par le DCA et d’anticiper d’éventuels
problèmes d’intégration sur les environnements de l’administration.
Sous-prestation 6.2 :
Le développement étant réalisé dans les locaux du titulaire, ce dernier met à
disposition et assure le maintien en condition opérationnelle de l’ensemble des
infrastructures logicielles et matérielles (équipements serveurs et réseaux)

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 73 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

nécessaires au projet.
Le titulaire met notamment à disposition de l’administration les infrastructures
logicielles et matérielles suivantes :
- les produits logiciels correspondant à l’ingénierie et aux solutions de
développement utilisées par le titulaire sur sa plateforme de réalisation
des prestations ;
- les produits matériels nécessaires à la mise en place des plateformes.
Le titulaire met en œuvre tous les moyens nécessaires pour garantir
l’adaptation et le dimensionnement des infrastructures logicielles et
matérielles nécessaires au projet sur la durée de l’accord-cadre, sans
frais supplémentaires pour l’administration.

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les livrables

figurants dans l’annexe 1 du CCTP intitulée « Découpage des prestations et
des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 74 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XVII. PRESTATION 7 (P7) : REVERSIBILITÉ ET TRANSFERT DES ACQUIS

Objectifs Cette prestation a pour but d’organiser, en fin de marché, un transfert de

connaissances du titulaire, aux personnels désignés par l’administration.
Le titulaire assure cette prestation, au personnel de l’administration ou à
toute autre personne désignée par celle-ci (autre prestataire le cas échéant).
Il s’interdit de faire obstacle à cette décision et s’engage à apporter toute
l’assistance nécessaire à la parfaite exécution de cette opération.
La durée maximale de cette prestation est de quatre (4) mois.

Prérequis fournis Communication par l’administration des coordonnées complètes de ses

par l’administration interlocuteurs ou du tiers désigné pour le transfert des connaissances.

Modalités de Cette prestation se déclenche par l’émission d’un bon de commande

commande conformément aux dispositions du CCAP.

Activités et tâches à Les actions suivantes constituent un minimum attendu de la part du titulaire.
réaliser Celui-ci peut être force de proposition pour les compléter :
 étape de préparation :
o fourniture du plan de la phase de réversibilité à fournir au
maximum une (1) semaine après le début de la réversibilité ;
 étape de transfert de connaissances ;
o transmission de la totalité des livrables à jour (sources,
documentations, historique, maintenances à venir, etc.) ;
o communication de toutes les données nécessaires au
maintien en conditions opérationnelles ;
o réalisation des supports de formations résumant les points
vus et objectifs de chaque formation,
o formations des équipes du repreneur (méthodologie,
ingénierie, plates-formes et outils), elles seront réalisées sur
les environnements de développement.
o Evaluation du repreneur de la réalité du transfert de
compétence,
 étape de monitorat :
o implication du repreneur et accompagnement dans la
conduite d'actions de maintenance ainsi que dans les tests
associés.

Livrables A l’issue de la sous-prestation, le titulaire remet à l’administration les

livrables figurants dans l’annexe 1 du CCTP intitulée « Découpage des
prestations et des livrables » (ci-après DPL) dans les délais mentionnés.
Le titulaire peut être force de propositions pour compléter ces derniers s’il le
juge utile.

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 75 | 76
 CCTP Ŕ AMOE - SI Outils Numériques du Contrôle Automatisé

XVIII. ANNEXE 1 – DECOUPAGE DES PRESTATIONS ET DES LIVRABLES

Cette annexe fait l’objet d’un document séparé du présent CCTP.

XIX. ANNEXE 2 – CCT DU MINISTERE DE L’INTERIEUR

Cette annexe fait l’objet d’un document séparé du présent CCTP.

XX. ANNEXE 3 – PRESENTATION DU SI DES OUTILS DU CONTROLE AUTOMATISE

Cette annexe fait l’objet d’un document séparé du présent CCTP.

XXI. ANNEXE 4 – PSSI DU MINISTERE DE L’INTERIEUR

Cette annexe fait l’objet d’un document séparé du présent CCTP

XXII. ANNEXE 5 – PSSI DES OUTILS DU DCA (EX SIDCA)

Cette annexe fait l’objet d’un document séparé du présent CCTP

XXIII. ANNEXE 6 – PSSI DE L’ANTAI

Cette annexe fait l’objet d’un document séparé du présent CCTP

XXIV. ANNEXE 7 – PRESENTATION DES IHM DU SI

Cette annexe fait l’objet d’un document séparé du présent CCTP

CCTP-AMOE-SI Outils numériques du contrôle automatisé

P a g e 76 | 76