# Evolution et maintenance du système d'Information Agrosyst pour l'INRA : Cahier des clauses techniques particulières (CCTP)

Estelle Ancelet, Ophélie Jolys, Nicolas Munier-Jolain, Antoine Schellenberger, Morgane Dubuc

► To cite this version:

Estelle Ancelet, Ophélie Jolys, Nicolas Munier-Jolain, Antoine Schellenberger, Morgane Dubuc. Evolution et maintenance du système d'Information Agrosyst pour l'INRA : Cahier des clauses techniques particulières (CCTP). 55 p., 2016. hal-01607819

HAL Id: hal-01607819

https://hal.science/hal-01607819v1

Submitted on 5 Jun 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY-SA 4.0 - Attribution - ShareAlike - International
License
# ÉVOLUTION ET MAINTENANCE DU SYSTEME D'INFORMATION AGROSYST POUR L'INRA

## Cahier des Clauses Techniques et Particulières (CCTP)

<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /></figure>

INRA
SCIENCE & IMPACT

ÉCOPHYTO
DEPHY

Réseau de Démonstration, Expérimentation et Production de références sur les systèmes économies en phytosanitaires

ÉCOPHYTO
RÉDUIRE ET AMÉLIORER L'UTILISATION DES PHYTOS
Table des matières

<table><tbody><tr><td><strong>Cahier 1 : Présentation générale du projet</strong></td><td><strong>6</strong></td></tr><tr><td>1 Présentation du contexte</td><td>7</td></tr><tr><td>2 Objectifs de l'application</td><td>8</td></tr><tr><td>3 Organisation des acteurs du projet</td><td>8</td></tr><tr><td>4 Présentation du marché</td><td>9</td></tr><tr><td><strong>Cahier 2 : Description fonctionnelle de l'application</strong></td><td><strong>10</strong></td></tr><tr><td>5 Présentation de l'application</td><td>11</td></tr><tr><td><strong>Cahier 3 : Utilisateurs, rôles, et contrôle d'accès</strong></td><td><strong>15</strong></td></tr><tr><td><strong>Cahier 4 : État de l' existant et contraintes techniques</strong></td><td><strong>17</strong></td></tr><tr><td>6 Historique du Système d'Information</td><td>18</td></tr><tr><td>7 Architecture applicative</td><td>18</td></tr><tr><td>8 Architecture technique & serveurs</td><td>20</td></tr><tr><td>9 Statistiques</td><td>21</td></tr><tr><td>10 Documentation</td><td>21</td></tr><tr><td>11 Outils de développement</td><td>22</td></tr><tr><td>12 Modélisation UML</td><td>22</td></tr><tr><td>13 Performances</td><td>23</td></tr><tr><td>14 Interface utilisateur</td><td>23</td></tr><tr><td>15 Environnement techniques, contexte d'utilisation et déploiement de l'application</td><td>24</td></tr><tr><td><strong>Cahier 5 : Gestion du projet – Gouvernance – Gestion des risques</strong></td><td><strong>26</strong></td></tr><tr><td>16 Planification du projet</td><td>27</td></tr><tr><td>17 Gestion de projet</td><td>27</td></tr><tr><td>18 Organisation et structures</td><td>27</td></tr><tr><td>19 Plan d'assurance qualité (PAQ)</td><td>29</td></tr><tr><td>20 Gestion des anomalies</td><td>30</td></tr><tr><td>21 Tests et Recettes</td><td>31</td></tr><tr><td><strong>Cahier 6 : Description des prestations attendues</strong></td><td><strong>33</strong></td></tr><tr><td>22 Fréquence et types de commande des prestations</td><td>34</td></tr><tr><td>23 Conditions d'exécution des prestations</td><td>34</td></tr><tr><td>24 Description des prestations</td><td>35</td></tr><tr><td>25 Développements prévisibles</td><td>44</td></tr><tr><td><strong>Cahier 7 : Mise en œuvre par le titulaire</strong></td><td><strong>45</strong></td></tr><tr><td>26 Organisation du titulaire</td><td>46</td></tr><tr><td>27 Périodes et délais</td><td>46</td></tr><tr><td>28 Développements en mode projet</td><td>51</td></tr><tr><td>29 Sécurité du système d'information</td><td>52</td></tr><tr><td><strong>Cahier 9 : Annexes</strong></td><td><strong>54</strong></td></tr><tr><td>30 Liste des annexes</td><td>55</td></tr><tr><td>31 Glossaire des abréviations</td><td>55</td></tr><tr><td>32 Auteurs</td><td>55</td></tr></tbody></table>
Sommaire détaillé

Cahier 1 : Présentation générale du projet................................................................................ 6

1 Présentation du contexte ................................................................................................................ 7

1.1 Plan ECOPHYTO, réseau DEPHY et Agrosyst........................................................................ 7

1.2 L'INRA .................................................................................................................................................. 7

2 Objectifs de l'application ................................................................................................................ 8

3 Organisation des acteurs du projet ................................................................................................ 8

3.1 Les acteurs du projet ................................................................................................................ 8

3.2 L'équipe projet .......................................................................................................................... 9

4 Présentation du marché .................................................................................................................. 9

4.1 Objet du marché.......................................................................................................................... 9

Cahier 2 : Description fonctionnelle de l'application ................................................................ 10

5 Présentation de l'application ........................................................................................................ 11

5.1 Présentation générale ................................................................................................................ 11

5.2 Schéma synthétique des données collectées........................................................................ 12

5.3 Données millésimées - Filiation.................................................................................................. 14

5.4 Guide de l'utilisateur .................................................................................................................. 14

Cahier 3 : Utilisateurs, rôles, et contrôle d'accès ........................................................................ 15

Cahier 4 : État de l'existant et contraintes techniques................................................................ 17

6 Historique du Système d'Information.................................................................................................. 18

7 Architecture applicative.......................................................................................................................... 18

8 Architecture technique & serveurs........................................................................................................ 20

9 Statistiques.................................................................................................................................................. 21

10 Documentation ........................................................................................................................................ 21

11 Outils de développement ................................................................................................................ 22

11.1 Environnement de développement .................................................................................................. 22

11.2 Gestionnaire de codes sources (SCM) .................................................................................. 22

11.3 Forge logicielle.......................................................................................................................... 22

12 Modélisation UML.................................................................................................................................. 22

13 Performances........................................................................................................................................ 23

14 Interface utilisateur.................................................................................................................................. 23

14.1 Charte graphique.......................................................................................................................... 23

14.2 Ergonomie ........................................................................................................................................ 23

14.3 Postes clients et Navigateurs........................................................................................................ 24

15 Environnement techniques, contexte d'utilisation et déploiement de l'application ................ 24

15.1 Phase de développement.................................................................................................................. 24

15.2 Phase de VA........................................................................................................................................ 25

15.3 Phase de VSR et période de garantie .......................................................................................... 25

15.4 Phase de production.......................................................................................................................... 25

Cahier 5 : Gestion du projet – Gouvernance – Gestion des risques.................................................. 26

16 Planification du projet.......................................................................................................................... 27
<table><tbody><tr><td>17 Gestion de projet</td><td>27</td></tr><tr><td>18 Organisation et structures</td><td>27</td></tr><tr><td>18.1 Comité de pilotage d'Agrosyst</td><td>27</td></tr><tr><td>18.2 Comité de pilotage du marché</td><td>27</td></tr><tr><td>18.3 Equipe projet INRA</td><td>28</td></tr><tr><td>18.4 Comité opérationnel de suivi</td><td>28</td></tr><tr><td>18.5 Réunions de travail</td><td>28</td></tr><tr><td>18.6 Communication INRA - Titulaire</td><td>29</td></tr><tr><td>18.7 Relations avec d'autres acteurs</td><td>29</td></tr><tr><td>19 Plan d'assurance qualité (PAQ)</td><td>29</td></tr><tr><td>20 Gestion des anomalies</td><td>30</td></tr><tr><td>21 Tests et Recettes</td><td>31</td></tr><tr><td>Cahier 6 : Description des prestations attendues</td><td>33</td></tr><tr><td>22 Fréquence et types de commande des prestations</td><td>34</td></tr><tr><td>23 Conditions d'exécution des prestations</td><td>34</td></tr><tr><td>24 Description des prestations</td><td>35</td></tr><tr><td>24.1 Prise en main initiale</td><td>36</td></tr><tr><td>24.2 Développements en mode projet</td><td>37</td></tr><tr><td>24.2.1 Avant-projet : cadrage de la réalisation du projet</td><td>37</td></tr><tr><td>24.2.2 Réalisation du projet</td><td>38</td></tr><tr><td>24.2.3 Intégration des réalisations INRA</td><td>40</td></tr><tr><td>24.2.4 Tests fonctionnels des copier/coller d'interventions réalisées (cas pratique)</td><td>41</td></tr><tr><td>24.3 Services et prestations complémentaires</td><td>41</td></tr><tr><td>24.3.1 Analyses fonctionnelles et techniques</td><td>41</td></tr><tr><td>24.3.2 Formation : transfert technique</td><td>42</td></tr><tr><td>24.4 Réversibilité</td><td>43</td></tr><tr><td>24.5 Définition des indicateurs</td><td>44</td></tr><tr><td>25 Développements prévisibles</td><td>44</td></tr><tr><td>Cahier 7 : Mise en œuvre par le titulaire</td><td>45</td></tr><tr><td>26 Organisation du titulaire</td><td>46</td></tr><tr><td>27 Périodes et délais</td><td>46</td></tr><tr><td>27.1 Prise en main initiale</td><td>47</td></tr><tr><td>27.2 Développements en mode projet</td><td>47</td></tr><tr><td>27.2.1 Avant-projet</td><td>47</td></tr><tr><td>27.2.2 Réalisation du projet</td><td>47</td></tr><tr><td>27.2.3 Intégration des réalisations INRA</td><td>48</td></tr><tr><td>27.2.4 Opérations de vérification et garantie</td><td>49</td></tr><tr><td>27.2.5 Formation : transfert technique</td><td>50</td></tr><tr><td>27.2.6 Réversibilité</td><td>50</td></tr><tr><td>28 Développements en mode projet</td><td>51</td></tr><tr><td>28.1 Cadrage de la réalisation du projet</td><td>51</td></tr><tr><td>28.1.1 Chiffrage de la phase de cadrage</td><td>51</td></tr><tr><td>28.1.2 Détermination des délais de livraison</td><td>51</td></tr><tr><td>28.1.3 Chiffrage des évolutions</td><td>51</td></tr></tbody></table>
<table><tr><td>28.1.4 Chiffrage de l'intégration des réalisations Inra</td><td>52</td></tr><tr><td>28.2 Mise en œuvre de la réalisation du projet</td><td>52</td></tr><tr><td>29 Sécurité du système d'information</td><td>52</td></tr><tr><td>29.1 Obligation en termes de sécurité</td><td>52</td></tr><tr><td>29.2 Confidentialité</td><td>53</td></tr><tr><td>29.3 Sauvegarde</td><td>53</td></tr><tr><td>Cahier 9 : Annexes</td><td>54</td></tr><tr><td>30 Liste des annexes</td><td>55</td></tr><tr><td>31 Glossaire des abréviations</td><td>55</td></tr><tr><td>32 Auteurs</td><td>55</td></tr></table>
# Cahier 1 : Présentation générale du projet
# 1 Présentation du contexte

## 1.1 Plan ECOPHYTO, réseau DEPHY et Agrosyst

Le **plan Ecophyto** vise à réduire progressivement l'utilisation de produits phytosanitaires en France par rapport à la référence 2008. Piloté par le Ministère de l'agriculture, de l'agroalimentaire et de la forêt, ce plan se décline en plusieurs actions dont la mise en place d'un réseau national de démonstration, d'expérimentation et de production de références sur des systèmes de culture économes en produits phytosanitaires : le réseau DEPHY. Un système de culture est défini, pour une portion d'espace traitée de manière homogène (par exemple : un groupe de parcelles), par les cultures qui y sont pratiquées, leur ordre de succession et les interventions effectuées sur chacune d'elles.

Le **réseau DEPHY** rassemble près de 2000 exploitations agricoles (DEPHY-FERME) et 180 domaines expérimentaux (DEPHY-EXPE) autour d'un même objectif : la réduction de l'utilisation des produits phytosanitaires en maintenant une agriculture économiquement performante. Couvrant l'ensemble du territoire national, ce réseau a la particularité de partir des initiatives de groupes d'agriculteurs testant, directement sur leurs fermes, des systèmes de culture adaptés pour limiter la dépendance aux pesticides, avec des stratégies variées, et des niveaux de réussite également très divers par rapport à cet objectif. Un tel réseau est source d'une quantité importante de données.

L'Institut National de la Recherche Agronomique (INRA) a reçu délégation de réalisation d'un système d'information dédié à la collecte et à l'exploitation d'informations en provenance du réseau DEPHY. Nommé **Agrosyst**, le système d'information développé pour le compte du réseau DEPHY par l'INRA, a l'ambition de devenir l'outil de référence pour centraliser les informations sur les pratiques culturales en France.

## 1.2 L'INRA

L'Institut National de la Recherche Agronomique est un Établissement Public à caractère Scientifique et Technologique (EPST). Cet organisme national de recherche publique est placé sous la tutelle du Ministère de l'Education Nationale, de l'Enseignement Supérieur et de la Recherche (MENESR) et du Ministère de l'Agriculture, de l'Agroalimentaire et de la Forêt (MAAF).

En 2014, l'INRA rassemble près de 8290 agents titulaires. Ses 186 unités de recherche et 48 unités expérimentales sont réparties sur 13 départements scientifiques touchant l'agriculture, l'alimentation et l'environnement et dans 17 centres régionaux.

Une présentation de l'Institut, son organisation, ses activités, est disponible sur le site http://www.inra.fr/.

Le système d'information concerné par cet appel d'offres relève de la direction scientifique Agriculture ainsi que du département de recherche « Environnement et Agronomie ».
## 2 Objectifs de l'application

En capitalisant les données du réseau DEPHY, Agrosyst a pour ambition de faciliter leur analyse transversale et leur valorisation afin d'identifier les systèmes de culture les plus performants, et de favoriser la transmission de ces derniers à d'autres conseillers et d'autres agriculteurs.

L'application doit assurer les fonctions suivantes :

* L'acquisition et l'hébergement de données de natures différentes (succession des cultures, interventions pratiquées sur les cultures, règles de décision, mesures, observations, etc.) ;

* le calcul de variables de synthèse, de bilans, de différents indicateurs, de rapports, etc. ;

* l'interopérabilité avec d'autres systèmes (import et exports de données).

L'application Agrosyst est opérationnelle et déployée dans le réseau DEPHY depuis mars 2014, mais son développement se poursuit pour ajouter progressivement des fonctionnalités.

## 3 Organisation des acteurs du projet

### 3.1 Les acteurs du projet

<table><thead><tr><td>Désignation</td><td>Détails</td><td>Rôle</td></tr></thead><tbody><tr><td>COMITE DE PILOTAGE</td><td>Représentants de la Direction Scientifique Agriculture et du département Environnement et Agriculture de l'INRA, de la Cellule d'Animation Nationale de DEPHY (CAN DEPHY), du MAAF, des Instituts Techniques Agricoles, de l'unité Infosol, et équipe Agrosyst</td><td>Fournit les orientations stratégiques du projet</td></tr><tr><td>COMITE DES PARTENAIRES</td><td>Représentants des organismes mettant à disposition de l'INRA des référentiels pour Agrosyst</td><td>Définit les règles d'utilisation des bases de données de référence Etudie les demandes d'utilisation d'Agrosyst hors DEPHY</td></tr><tr><td>EQUIPE PROJET</td><td>Agents de l'INRA</td><td>Assure la direction du projet et la coordination avec le PRESTATAIRE Accompagne les UTILISATEURS. Participe ponctuellement aux développements de l'application</td></tr><tr><td>UTILISATEURS</td><td>Agents des chambres d'agriculture, des Centres d'Initiatives pour Valoriser l'Agriculture et le Milieu Rural (CIVAM), de coopératives agricoles, d'Instituts Techniques Agricoles, de l'INRA, etc. Les profils d'utilisateurs sont variés : techniciens, agronomes, chercheurs etc.</td><td>Utilisent l'application Testent l'application Chaque utilisateur, selon son profil, utilisera différentes fonctionnalités de l'application : certains se concentrent sur la saisie et le calcul d'indicateurs, d'autres sur la supervision des saisies, d'autres encore sur l'analyse globale de la</td></tr></tbody></table>
<table><tr><td></td><td></td><td>BDD</td></tr><tr><td>PRESTATAIRE DE SERVICE INFORMATIQUE</td><td>Société retenue au titre du présent marché. Aussi appelé titulaire dans les différents documents de cet appel d'offre.</td><td>Réalise les prestations demandées dans le cadre du présent marché</td></tr></table>

## 3.2 L'équipe projet

L'INRA a mis en place une équipe projet composée de deux informaticiens et de trois agronomes. Ses missions principales sont :

* Le pilotage du développement d'Agrosyst (expressions des besoins, validation des spécifications, participation au codage, animation du groupe des testeurs);

* Le déploiement d'Agrosyst au sein du réseau DEPHY et au-delà (formation et accompagnement des utilisateurs);

* Le suivi du présent marché et de tous les aspects contractuels et financiers;

* La contribution au rayonnement d'Agrosyst et de ses potentialités.

Les informaticiens sont en poste à Orléans et les agronomes sont en poste à Dijon.

# 4 Présentation du marché

## 4.1 Objet du marché

Le présent marché a pour objet la maintenance et le développement de nouvelles fonctionnalités de l'application Agrosyst pour le compte de l'INRA. Ces développements se feront à partir de l'application existante.
Cahier 2 : Description fonctionnelle
de l'application
# 5 Présentation de l'application

## 5.1 Présentation générale

Agrosyst est une application disponible sur internet et accessible après authentification. L'application est organisée en menus et sous-menus dirigeant l'utilisateur vers différents formulaires de saisie, soit au total une quarantaine d'écrans différents.

Les différentes fonctionnalités assurées par Agrosyst sont les suivantes :

* saisie de données (cf.5.2 - Schéma synthétique des données collectées);

* stockage des données;

* astuces facilitant la saisie;

* calcul d'indicateurs pouvant faire appel à de nombreuses données saisies et exports de ces indicateurs au format .xls;

* export de données en .xls;

* import de données en .xls et XML (format standard d'échange de données Agronomiques : eDaplos);

* anonymisation des données sensibles pour les profils utilisateurs qui n'ont pas le droit d'accéder;

* administration de l'application (gestion des utilisateurs, mise à jour des référentiels, diffusion de messages).

La saisie des données dans les différents champs des formulaires peut s'effectuer de différentes façons. Il peut s'agir de saisie libre, de saisie contrôlée (contrôles sur le format, sur la cohérence avec un autre menu, etc.), de choix parmi une liste de données de référence. Le contenu des formulaires peut varier selon le remplissage d'un champ (ex. : suivant le choix du type de domaine, suivant le choix de la filière, etc.).

Les astuces facilitant la saisie sont des fonctionnalités à disposition des utilisateurs pour qu'ils passent le moins de temps possible à effectuer des saisies redondantes, et pour qu'ils trouvent rapidement une réponse en cas de problème. Le temps ainsi dégagé peut être mis à profit pour l'analyse de ces données via les indicateurs proposés par Agrosyst. Parmi ces fonctionnalités, il y a :

- l'accès au mode d'emploi;

- la possibilité d'envoyer des questions à l'équipe projet depuis l'interface;

- l'ajout automatique d'informations dans un formulaire en fonction de saisies effectuées en amont;

- la possibilité de copier-coller les informations des interventions culturales au sein d'une même exploitation agricole (au sein de la même campagne agricole ou non);

- la possibilité de dupliquer les systèmes synthétisés au sein d'une même exploitation agricole (au sein de la même campagne agricole ou non). La duplication permet de copier/coller une entité et toutes les autres liées, sans qu'ils ne soient tous visibles à l'écran.

- la possibilité de copier-coller les informations du parc matériel et des combinaisons d'outils entre différentes exploitations agricoles.

Les fonctionnalités de copier-coller et de duplication nécessite de bien gérer des données de plusieurs campagnes d'un même domaine. Il faut notamment détecter si les éléments attendus dans la campagne cible sont présents pour autoriser ou non le copier-coller. Par exemple, pour copier-coller une intervention saisie sur une parcelle en 2015 vers une parcelle du même domaine en 2016, il faut s'assurer que le matériel associé à l'intervention en 2015 existe aussi dans la campagne 2016. Des règles ont été également définies pour copier-coller des interventions portant sur une culture vers une culture différente. En effet, l'affichage de certaines informations au sein d'une intervention dépend de
la culture sur laquelle elle porte. Plus de détails à ce propos figurent dans le fichier de définition des règles de copier/coller du cas pratique de cet appel d'offre et dans le § 5.3 - Données millésimées - Filiation.

Les fonctionnalités d'administration du SI concernent la gestion des comptes des utilisateurs et des référentiels de données. Ces référentiels peuvent alimenter les listes de l'interface, ils permettent d'harmoniser les saisies d'utilisateurs et ainsi facilitent leur exploitation (ex. : liste de matériels agricoles, liste d'espèces). Les référentiels de données peuvent aussi être utilisés pour le calcul d'indicateurs sur les données saisies par les utilisateurs (ex. : toxicité de produits phytosanitaires pour calculer un indicateur environnemental). Agrosyst se base sur une centaine de référentiels de données, et ce nombre augmentera au fil des évolutions du SI.

Certains référentiels doivent régulièrement être mis à jour. Les fournisseurs de référentiels envoient les nouvelles données à l'équipe Agrosyst qui les met en forme puis les importe dans Agrosyst au format csv. Chaque ligne à importer est identifiée par une « clé d'identification ». Si une ligne avec cette clé existe déjà dans le référentiel, la ligne existant dans le référentiel est remplacée par la ligne à importer, si aucune ligne avec cette clé n'existe, la ligne est ajoutée au référentiel.

Le grand nombre d'écrans, les interactions entre ces derniers, les différentes possibilités d'utilisation d'Agrosyst sont à l'image de la complexité de l'objet étudié : le système de culture. L'appréhension de l'application par un utilisateur nécessite à minima une journée de formation.

## 5.2 Schéma synthétique des données collectées

Le schéma suivant synthétise les différentes entités d'Agrosyst et met en évidence quelques-unes des interactions entre ces dernières.

### Organisation de l'interface

En gris, sont représentés les menus de la barre principale des menus de l'interface. Dans ces menus, on peut accéder aux formulaires de saisie de différentes entités, formulaires comprenant plusieurs onglets. Par exemple, dans le formulaire « Domaine », on trouve les onglets « Parc Matériel », « Cultures », etc. Par soucis de simplification, les onglets des formulaires n'ont pas tous été représentés ci-dessous.
<figure><img src="image_4.png" /><figcaption>Figure 1 : Schéma synthétique des données collectées par Agrosyst</figcaption></figure>

## Données collectées – Quelques notions métier

Un **domaine** est une exploitation agricole, un site expérimental ou une ferme de lycée agricole. On y décrit le parc matériel, les cultures, les parcelles. Chaque parcelle du domaine peut appartenir à un système de culture.

Chaque domaine comprend un ou plusieurs **dispositifs**. Un dispositif est un élément organisationnel qui permet de regrouper des systèmes de culture (SdC) suivis de façon coordonnée sur un domaine, par exemple les SdC suivis avec le même protocole ou les SdC mis en place dans le cadre d'un même projet.

Un **système de culture** est défini, pour une portion d'espace traitée de manière homogène (par ex. : un groupe de parcelles), par les cultures qui y sont pratiquées, leur ordre de succession et les itinéraires techniques (i.e. les interventions culturales) mis en œuvre pour chacune d'elles.
Dans Agrosyst, un domaine peut contenir un ou plusieurs systèmes de culture regroupés dans un ou plusieurs dispositifs. La description du système technique du système de culture s'effectue avec les **actes réalisés** et/ou des **actes synthétisés**. La description du système décisionnel s'effectue avec le renseignement du **mode de gestion** et des **règles de décision**.

Les **actes réalisés** permettent de décrire les événements qui se sont déroulés sur les parcelles d'un système de culture pour une campagne donnée : culture(s) présente(s), interventions culturales, mesures et observations.

Les **actes synthétisés** permettent de décrire une synthèse des événements se déroulant au sein du système de culture pour une campagne – il s’agit alors d’un « synthétisé annuel », ou pour plusieurs campagnes, il s’agit alors d’un « synthétisé pluriannuel ». S’il s’agit d’un système de cultures assolées, l’utilisateur va commencer par décrire la rotation des cultures au sein du SdC puis les interventions effectuées sur chaque couple culture*précédent cultural. S’il s’agit d’un système de cultures pérennes, l’utilisateur va décrire les caractéristiques des cultures pérennes présentes au sein du SdC, et les
interventions sur chacune de ces cultures. Dans le synthétisé, la notion spatiale de « parcelle » n'est plus utilisée.

Par exemple, dans le réalisé, on trace ce qui se passe sur chaque parcelle du SdC même si ces parcelles ont été semées avec la même culture : « en 2015, sur la parcelle 1, j'ai semé le blé le 20 octobre ; sur la parcelle 2, le 21 octobre ». Dans le synthétisé, on fera une synthèse de ce qui est fait pour une culture même si cette culture est présente sur différentes parcelles : « pour mes blé ayant pour précédent cultural le colza, je sème en général le 20 octobre ».

Dans le menu « **Performances** », on peut lancer le calcul d'indicateurs sur les données du réalisé (i.e. des actes réalisés) ou du synthétisé (i.e. des actes synthétisés). Les résultats des calculs sont téléchargeables dans un fichier Excel.

## 5.3 Données millésimées - Filiation

La description de certaines entités est millésimée. Par exemple, les caractéristiques du domaine sont décrites campagne par campagne<fnref n="1" />. Cela permet à l'utilisateur de tracer divers changements au sein du domaine au cours du temps : acquisition d'un nouveau matériel, nouvelle culture, etc. Il existe donc une notion de **filiation** dans le SI pour reconnaitre qu'une entité est la même au fil du temps (i.e année après année) mais possède des caractéristiques qui peuvent varier ou non d'une campagne à l'autre.

La description du « synthétisé pluriannuel » mobilise les données de plusieurs campagnes du domaine. Sa saisie implique des mécanismes plus complexes que dans celle des actes réalisés. En effet, il faut pouvoir mobiliser des données sur plusieurs campagnes sans redondance (par exemple une même combinaison d'outil ne doit pas être proposée plusieurs fois dans les menus s'il elle existe pour plusieurs campagnes). Pour cela, Agrosyst utilise le système de filiation évoqué ci-dessus.

Plus de détails à ce propos figurent dans le fichier de définition des règles de copier/coller du cas pratique de cet appel d'offre.

## 5.4 Guide de l'utilisateur

Pour mieux comprendre le fonctionnement de l'application, vous trouverez le Guide de l'Utilisateur en annexe.

<footnote n="1">¹ Une campagne agricole court généralement de septembre de l'année n à septembre de l'année n+1. L'année n+1 est l'année de récolte, c'est l'année utilisée pour nommer une campagne agricole dans Agrosyst.</footnote>
Cahier 3 : Utilisateurs, rôles, et
contrôle d'accès
Le profil des utilisateurs d'Agrosyst est varié. Les utilisateurs peuvent être des conseillers agricoles, des expérimentateurs, des porteurs de projet de recherche, des chargés de mission de la Cellule d'Animation Nationale du réseau DEPHY, etc. Chaque utilisateur n'aura donc pas la même utilisation de l'application. Certains se concentrent sur la saisie et le calcul d'indicateurs, d'autres sur la supervision des saisies, d'autres encore sur l'analyse globale de la base de données.

Agrosyst est accessible uniquement après identification de l'utilisateur. Les utilisateurs interagissent avec l'application en fonction des droits qui leur ont été attribués.

Un profil utilisateur est constitué d'une combinaison de droits sur les périmètres de l'application. Les différents périmètres sont :

* l'ensemble du SI ;

* les réseaux ;

* les domaines ;

* les dispositifs et les systèmes de culture.

Calquant le fonctionnement du réseau DEPHY, ce système de gestion des utilisateurs et des rôles a pour objectif de répartir la charge sur le plus grand nombre possible d'utilisateurs tout en garantissant d'une part la confidentialité des données et, d'autre part, le bon déroulement des phases de saisie et de validation du réseau DEPHY.

Les différents rôles et droits des utilisateurs sont les suivants :

* administrateur fonctionnel ;

* responsable réseau ;

* responsable domaine ;

* responsable dispositif ;

* exploitant (de données) SI ;

* exploitant (de données) SdC.

Ils sont détaillés dans le guide utilisateur, dans le chapitre 3 - Gestion des accès aux données & Rôles des utilisateurs.

On trouve également dans ce chapitre des informations sur la validation et l'anonymisation des données.
Cahier 4 : État de l'existant et
contraintes techniques
# 6 Historique du Système d'Information

La première mise en production du SI Agrosyst date de février 2014. La version actuelle est la 2.2 suite à une dizaine d'évolutions en 2 ans. Ces évolutions concernent des fonctionnalités variées :

- Améliorations ergonomiques

- Apports de compléments dans les formulaires de saisie

- Diminution des temps de réponse

- Amélioration de la déclaration des destinations des récoltes

- Amélioration de la déclaration des prix

- Transferts de données entre SI au format XML

- Ajout de référentiels

- Mise à jour de référentiels via des Web services

- Élargissement de la gamme d'indicateurs

# 7 Architecture applicative

La solution actuelle est basée sur les technologies suivantes :

## ➔ Architecture :

- Langage : Java 8

- SGBD : PostgreSQL 9.1² (prod), H2 (dev)

## ➔ Frameworks :

- Gestion de l'IHM : Struts 2.3, jQuery 1.12.4, AngularJS 1.2.26, Wro4j 1.7.9

- Injection de classes : Spring 4.1.5

- Persistence des données : Eugene 2.13, Topia 3.0,Hibernate 4.3.11.Final

- Tests : JUnit 4.12

## ➔ Compilation, structuration des répertoires et gestion des dépendances : MAVEN
4.0.0.

## ➔ Analyse de code : Sonar

Le système d'information décrit dans ce document a été conçu dans un souci d'évolutivité. Il sera amené à évoluer encore pendant plusieurs années de différentes façons : par l'ajout de nouvelles fonctions mais aussi par l'évolution de l'existant. Cela implique le maintien d'une architecture applicative adaptée à ces contraintes. Elle sera structurée tant que possible en éléments indépendants pouvant être testés séparément.

Les contraintes suivantes seront à garantir par le prestataire :

- Le système ne doit pas être refondu, les nouveaux développements se baseront sur la version actuelle du logiciel ;

<footnote n="2">² Le SGBD PostgreSQL sera prochainement upgradé à une version 9.2 ou supérieure.</footnote>
→ L'usage de design patterns généraux et propres aux architectures distribuées sera fortement apprécié ;

→ Sur une architecture logique n-tiers, déployable indifféremment sur un ou plusieurs serveurs, au choix de l'INRA ;

→ Quand il s'agira d'exposer des services web, le protocole REST en appui à une implémentation de la spécification JAX-RS dans sa dernière version devra être utilisé. Leur description fera partie d'une documentation dont la forme reste à définir ;

→ La base de données n'embarque pas de procédures internes relevant de la gestion des fonctions métiers ;

→ Tous les échanges entre postes de travail et application sont effectués avec le protocole sécurisé https ;

→ Le code source doit être couvert par des tests unitaires qui porteront sur des classes pertinentes. En d'autres termes, il n'est pas attendu que les tests unitaires portent sur la totalité des classes de l'application. Pour la réalisation de ces tests, il pourra être nécessaire de développer des « bouchons » qui seront fournis et décrits ;

→ Les grandes fonctionnalités de l'application devront pouvoir être testées automatiquement par l'usage de frameworks ou de plateformes de tests (ex : Selenium) dédiés et intégrés au cycle de compilation MAVEN ;

→ Les futurs développements se feront uniquement avec des composants open-source ;

→ L'empilement des couches de composants est à éviter ;

→ Les montées de versions de différents composants seront réalisées par le titulaire qui devra conseiller l'INRA sur le moment opportun de les réaliser ;

→ La couche de service est indépendante des technologies utilisées pour réaliser l'IHM ; cela afin de permettre le changement de l'interface graphique et de sa charte sans remanier le code de la couche service (exemple : passer de Struts à ExtJS).

En respectant ces contraintes, **le titulaire devra être force de proposition** afin de permettre à l'INRA de **maîtriser la dette technique de son outil et de garantir son évolutivité**. Des améliorations techniques pourront ainsi être proposées par le candidat dans sa réponse ou par le titulaire tout au long du marché. Le choix d'un nouveau composant devra être argumenté auprès de l'INRA et validé.
# 8 Architecture technique & serveurs

L'architecture technique de l'application Agrosyst est la suivante :

<figure><img src="image_5.png" /><figcaption>Figure 2 : Architecture technique d'Agrosyst</figcaption></figure>

Toute l'infrastructure est hébergée par l'INRA.

En ce qui concerne les composantes logicielles des serveurs, l'INRA utilise les éléments suivants :

<table><thead><tr><td>Item</td><td>Énoncé</td></tr></thead><tbody><tr><td>Système d'exploitation</td><td>Ubuntu LTS.<br/>L'application ne nécessite pas les privilèges administrateur.</td></tr></tbody></table>
<table><caption>Figure 3 : Versions des logiciels serveurs</caption><thead><tr><td>Item</td><td>Énoncé</td></tr></thead><tbody><tr><td>Journaux et fichiers temporaires</td><td>L'application prévoit la rotation des journaux et la purge des fichiers temporaires. Il est nécessaire que cela continue.</td></tr><tr><td>Protocoles</td><td>Le seul protocole autorisé entre le poste client et le frontal Web est HTTPS.</td></tr><tr><td>Serveur HTTP</td><td>Apache 2.x (en frontal) avec redirection vers Tomcat via un connecteur maintenu</td></tr><tr><td>Serveur d'applications</td><td>Tomcat 7.0.59</td></tr><tr><td>JRE</td><td>1.8</td></tr><tr><td>Protocole WS</td><td>REST</td></tr></tbody></table>

Des montées de versions seront réalisées régulièrement par l'INRA.

## 9 Statistiques

L'application Agrosyst comprend à ce jour :

- 40 pages d'interface

- 120 000 lignes de codes (fichiers java, jsp, js)

- 2 000 fichiers de codes

- La description de 5 400 domaines

- Chacun pouvant avoir 1 000 interventions agricoles

- 530 utilisateurs

- 140 tables dans la BDD (dont 65 tables de référentiels et 3 pour la gestion des rôles) pour un total de 6 Go

## 10 Documentation

La documentation disponible sur Agrosyst est la suivante :

- Cahier des charges de la 1ère mise en production ;

- Guide utilisateur ;

- Forge du projet (avec wiki, spécifications et gestionnaire de tâches) utilisée depuis le début du projet ;

- Document de description de l'architecture technique.
# 11 Outils de développement

## 11.1 Environnement de développement

Le titulaire pourra utiliser l'environnement de développement avec lequel il est à l'aise. Il faudra cependant que le projet soit compatible avec l'environnement de développement Eclipse.

Le titulaire devra pouvoir être à même de répondre aux questions émanant de l'INRA dans son utilisation d'Eclipse, adjoint éventuellement de plugins permettant une meilleure intégration des frameworks utilisés, mais aussi de plugins permettant l'audit de tout ou partie de la qualité du code.

## 11.2 Gestionnaire de codes sources (SCM)

À la signature du marché, le SCM du projet sera SVN ou Git<fnref n="3" />. Le titulaire pourra demander à changer de SCM à condition d'argumenter son choix qui devra ensuite être validé par l'INRA.

Dans tous les cas, l'INRA doit dès le démarrage du projet avoir un accès (en lecture et écriture) au SCM contenant le code source du projet en cours d'écriture.

Le gestionnaire de code source utilisé pourra être celui de l'INRA (SVN).

L'installation, l'administration et la mise à disposition du dépôt de sources du projet à l'équipe informatique de l'INRA sera à la charge du titulaire.

**Remarque :**

La documentation technique du projet pourra également être versionnée au sein du SCM puis mise à disposition via le wiki de la forge logicielle (capable de pointer vers une ressource d'un SCM)

## 11.3 Forge logicielle

La forge logicielle utilisée pourra être celle du titulaire ou celle de l'INRA.

Cette forge devra communiquer en lecture avec le SCM. Le cas échéant, l'INRA paramétrera sa propre forge si nécessaire. Le titulaire devra alors conseiller l'INRA dans son paramétrage.

# 12 Modélisation UML

Actuellement, le modèle du domaine est représenté par un diagramme de classes UML, en utilisant le logiciel argoUML. Ce modèle est ensuite interprété par Eugene pour générer les entités java.

En dehors de cette utilisation d'UML, il ne sera pas fait recours à la modélisation UML.

Ces modèles UML constitueront des livrables à part entière

<footnote n="3">³ Actuellement sous SVN, le projet est susceptible de passer prochainement sous Git</footnote>
# 13 Performances

Les temps de réponse ci-dessous sont attendus dans le cadre d'un fonctionnement en conditions normales. Il est évident que la performance des différents réseaux est un facteur indépendant de l'application.

La mesure des performances se fera dans le contexte suivant :

* ➔ une connexion « haute performance » à 256 ko/s ;

* ➔ une connexion « de terrain » : la situation du poste de travail reste à définir.

Dans le cadre d'une connexion « haute performance », le temps d'affichage moyen d'une page dépendra de la fonction sous-jacente concernée :

* ➔ Lors d'une opération relevant du paramétrage, de la saisie, de l'identification, ce délai devra rester inférieur à la seconde ;

* ➔ Quand l'affichage dépend du résultat :

* ⇨ d'une requête issue d'une recherche, d'une opération de restitution, le délai sera jugé acceptable s'il reste inférieur à 3 secondes ;

* ⇨ d'une opération d'importation, de traitement ou d'exportation, le délai devra rester inférieur à 8 secondes.

Ces temps de réponse doivent être garantis pour 50 utilisateurs simultanés. À cette occasion, des tests de montée en charges devront être mis en place en s'appuyant sur des outils dédiés open source (JMeter, ...).

Si le nombre d'utilisateurs évolue positivement dans le temps, une « simple » évolution des caractéristiques des serveurs doit permettre de conserver ces temps de réponse.

Dans sa proposition, le soumissionnaire précisera la configuration matérielle souhaitée pour le ou les serveurs hébergeant l'application.

# 14 Interface utilisateur

L'interface utilisateur doit se révéler irréprochable en termes de qualité, de convivialité et de réactivité de l'interface graphique.

Dans sa réponse, le Candidat devra justifier de compétences dans ces domaines.

## 14.1 Charte graphique

Le titulaire devra respecter la charte graphique établie par le précédent prestataire et, si besoin, être force de proposition pour la faire évoluer, en accord avec l'INRA.

## 14.2 Ergonomie

La conception, l'ergonomie et la facilité d'utilisation de l'interface utilisateur doivent permettre la meilleure appropriation possible de l'application par ses différents utilisateurs.

La version actuelle s'est efforcée de répondre à cette attente et il est attendu du nouveau
titulaire que son expérience en termes de conception d'interfaces graphiques lui permette de
proposer à l'INRA des solutions équivalentes lors des développements à venir.

Le travail sur le contenu et la dynamique des écrans pourra se faire en s'appuyant sur des diagrammes UML (diagramme d'état et/ou d'activités) ainsi que des outils de maquettages.

14.3 Postes clients et Navigateurs

Les écrans affichés dans le navigateur doivent prendre en compte automatiquement la
résolution du poste client.

L'application devra fonctionner à 100 % de ses possibilités sur les navigateurs suivants (et versions supérieurs) :

➔ Firefox 4

➔ Chrome 13

➔ Internet Explorer 9

➔ Safari 7.1

➔ Opera 12

Dans toute autre configuration, l'application affiche un message informant l'utilisateur du risque d'un affichage dégradé.

15 Environnement techniques, contexte d'utilisation et
déploiement de l'application

La notion d'environnement technique comprend l'ensemble des serveurs logiques (Web, application, base de données, espace de stockage tiers si utile) et physiques nécessaires au bon fonctionnement de l'application.

Selon la phase du projet, le nombre et le type d'environnement pourront varier.

15.1 Phase de développement

Le développement sera guidé par les priorités fonctionnelles et techniques qui auront été discutées préalablement entre l'équipe projet informatique INRA et l'équipe projet du titulaire.

Sans attendre la livraison définitive d'un lot<fnref n="4" /> de développements, dès qu'un scénario significatif d'une fonctionnalité aura été développé, le titulaire déploiera sur un environnement de tests de pré-vérification une version intermédiaire de l'application. Chacune de ces versions intermédiaires fera l'objet d'une part d'un numéro de version ; et d'autre part d'une étiquette (tag) dans le SCM retenu. Ces numéros de versions intermédiaires seront utilisés par les testeurs lors de la remontée d'anomalies au sein de la forge logicielle.

<footnote n="4">⁴ Lot de développements : ici dans le sens d'une partie de l'ensemble des développements, à ne pas assimiler à la notion d'allotissement des marchés publics.</footnote>
Une fonctionnalité complexe pourra être développée sur une branche à part puis testée avant d'être intégrée au reste des développements.

L'accessibilité à cet environnement ne sera utile que lors des phases de tests. Il sera hébergé par l'INRA ou le titulaire, suivant le choix de l'INRA en concertation avec le titulaire.

**Remarque :**

La phase de pré-vérification est explicitée au paragraphe 21 - Tests et Recettes.

## 15.2 Phase de VA<fnref n="5" />

Avant la Mise en Ordre de Marche, une première validation à vocation fonctionnelle sera effectuée sur la plateforme du titulaire. D'abord par le titulaire (recette fournisseur) puis par l'INRA.

L'application fonctionnellement validée sera ensuite installée sur l'environnement de recette INRA. Lors de cette phase, cet environnement sera accessible au titulaire : chargement de l'application, de correctifs, etc. L'INRA convoquera lors de cette phase un groupe d'utilisateurs testeurs.

L'infrastructure matérielle qui accueillera le SI sera dotée d'une solution de virtualisation.

## 15.3 Phase de VSR<fnref n="6" /> et période de garantie

Le titulaire aura accès à un environnement de tests, identique en performances à l'environnement de production. L'accès à cet environnement de production sera réservé à l'INRA, sauf contraintes de services spécifiques.

## 15.4 Phase de production

Les deux environnements seront accessibles uniquement par l'INRA, celui de tests pouvant être ponctuellement ouvert au titulaire selon le contexte.

**Remarque :**

Pendant les phases de VA, de VSR et de garantie, le titulaire pourra demander ponctuellement à l'INRA d'effectuer des tests de pré-validation sur sa propre plateforme.

<footnote n="5">⁵ Vérification d'Aptitude ou recette utilisateur : aptitude de l'application à répondre aux besoins exprimés dans le cahier des charges.</footnote>

<footnote n="6">⁶ Vérification en Service Régulier : permet de vérifier l'aptitude du produit à répondre aux besoins des utilisateurs, en conditions réelles.</footnote>
Cahier 5 : Gestion du projet –
Gouvernance – Gestion des risques
# 16 Planification du projet

La durée du marché pour l'ensemble des prestations est stipulée dans l'acte d'engagement. Compte tenu d'une pression importante sur la date de disponibilité des nouvelles fonctionnalités, il est demandé que la prise en main initiale (voir 0) commence dès signature du marché (fin décembre, début janvier). Les phases de développement en mode projet (voir 27.2) succèderont rapidement.

# 17 Gestion de projet

En ce qui concerne la démarche de gestion de projet :

* L'accent est mis sur une approche collaborative, permettant à l'INRA de suivre la réalisation du projet et d'interagir, y compris pendant la phase de codage ;

* Ce que l'INRA ne veut pas : une réalisation avec un « effet tunnel » entre la validation des spécifications et la livraison.

Il est demandé au candidat de décrire dans sa réponse la manière dont s'organiseront la phase de prise en main initiale et le déroulement des phases de cadrage et de réalisation en accord avec les principes agiles, les différents comités définis dans la partie « 18 - Organisation et structures » et le détail des prestations attendues (24 - Description des prestations).

# 18 Organisation et structures

## 18.1 Comité de pilotage d'Agrosyst

Un comité de pilotage Agrosyst a lieu tous les 2 mois réunissant les pilotes du projet Agrosyst à l'INRA, au sein du réseau DEPHY et au ministère. L'équipe projet INRA fait, à cette occasion, un bilan de l'avancée des travaux et valide la planification à venir.

Le titulaire ne participera pas aux réunions de ce comité sauf demande des pilotes du projet.

## 18.2 Comité de pilotage du marché

Ce comité se réunira lors de la phase de prise en main de l'application puis à chaque demande de l'INRA ou du titulaire.

Regroupant les directeurs et chefs de projet de l'INRA et du titulaire, il pour but de :

- suivre le respect du marché (délai, facturation, pénalités...) et de s'assurer le cas échéant de l'adéquation des moyens par rapport à l'objectif du marché ;

- analyser les problèmes contractuels et les résoudre ;

- préciser les orientations du marché : clarifier les grandes orientations du domaine, valider les activités du titulaire ;

- suivre l'avancement opérationnel des travaux planifiés ;
- suivre les risques, intervenir en cas de litige, analyser les problèmes rencontrés non résolus et les résoudre (solutions ou plan d'actions).

Si le besoin se ressentait, l'INRA pourra choisir son ou ses interlocuteurs parmi l'équipe du titulaire.

L'ordre du jour est fixé par le titulaire en concertation avec l'INRA. Le titulaire réalisera le compte-rendu qui devra être validé par l'INRA dans la semaine suivant son envoi.

## 18.3 Equipe projet INRA

L'équipe projet INRA en charge d'Agrosyst est constituée d'agronomes et d'informaticiens à temps partiel ou à temps plein sur le projet. Elle est en charge de l'accompagnement et du suivi de la présente prestation pour l'INRA.

## 18.4 Comité opérationnel de suivi

Cette structure n'est pas une instance décisionnelle en tant que telle.

Ce comité a pour objectif de gérer le projet informatique au quotidien, entre autres : planification des développements, suivi opérationnel des phases, analyse des indicateurs d'avancement, actions, risques, mesure des écarts et impacts projet, état des livrables.

Il est constitué de représentants techniques (chefs de projet, développeurs, agronomes...) du titulaire et de l'INRA. Si le besoin se ressentait, l'INRA pourra choisir son ou ses interlocuteurs parmi l'équipe du titulaire.

Son mode de fonctionnement (réunion, audio ou visioconférence) et la fréquence des réunions pourront être adaptés au contexte ; un état des lieux formel au minimum toutes les semaines semble cependant nécessaire, notamment pour le suivi des périodes de réalisation des développements.

Il appartient au candidat de proposer un mode de fonctionnement de ce comité en adéquation avec les principes agiles et les règles du marché à bon de commandes.

Le relevé de décision de ces séances sera rédigé par le titulaire et validé par l'INRA dans un délai d'1 jour à 1 semaine (suivant la durée du comité).

## 18.5 Réunions de travail

La titulaire participera, pour mener à bien les prestations dont il a la charge, à un certain nombre de réunions de travail qu'il planifiera avec l'INRA, notamment :

- les réunions de présentation de spécifications par l'INRA ;

- les réunions de présentation des solutions techniques ;

- les réunions de transferts de compétences ;

- et, plus généralement, toute autre réunion de travail nécessaire, sur l'initiative de l'INRA.

Elles seront organisées et planifiées par le titulaire en concertation avec l'équipe INRA. Le titulaire assurera l'organisation de ces réunions et leur compte-rendu. L'INRA devra valider ce compte-rendu dans un délai de 7 jours.

Ces réunions pourront prendre différentes formes (présentiel, audio, visio) suivant le besoin.
## 18.6 Communication INRA - Titulaire

Pendant la durée de vie contractuelle du projet, les échanges se feront par l'intermédiaire d'une forge logicielle :

Elle sera utilisée à minima pour les fonctions suivantes :

* gestion des tâches et anomalies ;

* un espace de stockage et/ou un wiki (éventuellement associé à un SCM) accueillera l'ensemble de la documentation du projet. La structure de l'espace fera l'objet d'un accord entre l'INRA et le titulaire ;

Pour les communiqués à l'ensemble des partenaires du projet (ex : communiqué indiquant le déploiement d'une nouvelle version intermédiaire), une liste de diffusion mise en place par l'INRA sera utilisée.

Le candidat est libre de proposer tout outil visant à fluidifier les échanges entre les deux parties et améliorant la sauvegarde des informations en résultant. Le choix final reviendra à l'INRA.

Par ailleurs, l'INRA réalisant une partie des développements, le candidat proposera dans sa réponse des solutions afin d'intégrer les développeurs INRA dans l'équipe de développement.

Le format des documents échangés entre l'INRA et le titulaire sera choisi lors de la phase de prise en main de l'application parmi les formats usuels (Microsoft Office, Open Office, pdf).

## 18.7 Relations avec d'autres acteurs

Les relations du titulaire avec tous les acteurs autour du projet (fournisseurs de référentiels, utilisateurs, SI partenaires etc.) se font systématiquement par l'intermédiaire de l'équipe projet INRA.

## 19 Plan d'assurance qualité (PAQ)

Le titulaire rédige et tient à jour un plan d'assurance Qualité Maintenance (PAQ) du projet.

Le PAQ est validé par l'INRA.

Le PAQ est la référence de la démarche qualité aussi bien pour le titulaire que pour l'INRA.

Le PAQ comprend notamment les points suivants :

- les lignes directrices du PAQ,

- l'organisation qualité (rôles et responsabilités, principales tâches associées),

- le management de la qualité incluant :

* les modalités de mise en route des produits,

* le suivi et le soutien des intervenants,

* les procédures de vérifications,

* les procédures de traitement des modifications,
- l'identification et la traçabilité du projet (identification des versions successives, contrôles et essais finaux, livraison, procédures et enregistrements permettant la traçabilité),

- les conditions d'évolution du PAQ (responsabilités, approbations, ...),

- les normes et les standards de développement utilisés, notamment ceux relatifs à la documentation,

- la liste des produits à livrer, y compris la documentation associée,

- les procédures du processus de recette selon les types de prestations et de maintenance,

- les protocoles de tests et les indicateurs de résultats attendus,

- les outils de pilotage et indicateurs de suivi ainsi que les valeurs de référence calculées pour chaque indicateur.

Le projet de plan d'assurance qualité qui sera fourni par le soumissionnaire devra impérativement respecter les éléments concernant le processus de réalisation, les phases de validation, de tests, etc., fournis par l'INRA dans le DCE.

La non-conformité des éléments principaux du PAQ avec ces éléments entraînera systématiquement l'irrecevabilité de l'offre.

## 20 Gestion des anomalies

Sur la base d'un classement des anomalies selon trois niveaux (anomalie bloquante, majeure, mineure), les anomalies seront gérées selon la démarche suivante :

* Elles seront instruites et validées par une équipe dédiée de l'INRA : seule cette équipe sera habilitée à communiquer avec le titulaire à ce sujet. Les utilisateurs contactent cette équipe via une liste de diffusion ou l'interface de l'application.

* Le titulaire acquittera la prise de connaissance de l'anomalie, en indiquant qui la prend en charge, gérera le statut de l'anomalie.

* Le statut de l'anomalie passera par plusieurs états :

* **Nouvelle** : après avoir été validée en tant qu'anomalie, elle est déclarée par l'INRA en joignant toutes les informations, documents, copies d'écrans permettant au titulaire de comprendre la nature du problème ;

* **Acquittée** : le titulaire acte le fait qu'il a pris connaissance de l'anomalie ;

* **Prise en charge** : le titulaire indique qu'il travaille sur cette anomalie et qui s'en charge ;

* **En attente de précision** : le titulaire demande plus de précision dans la description de l'anomalie

* **Corrigée** : le titulaire indique qu'il a trouvé et fourni une solution ;

* **Rejetée** : le titulaire indique en argumentant qu'il ne s'agit pas d'une anomalie mais d'un comportement nominal et prévisible de l'application.

* **Fermée** : l'INRA valide le statut « Corrigée » ou « Rejetée » de la correction.

Le titulaire pourra proposer une autre classification s'il la juge plus appropriée.
Les délais de traitement d'une anomalie sont les suivants :

<table><thead><tr><th colspan="4">Niveau de l'anomalie</th></tr><tr><th></th><th>Bloquante</th><th>Majeure</th><th>Mineure</th></tr></thead><tbody><tr><th>Nouvelle</th><td colspan="3">jour J0, heure T0</td></tr><tr><th>Acquittée</th><td colspan="3">T0 + 6h</td></tr><tr><th>Prise en charge</th><td>J0 + 1</td><td>J0 + 2</td><td>J0 + 3</td></tr><tr><th>En attente de précision</th><td>J0 + 1</td><td>J0 + 2</td><td>J0 + 3</td></tr><tr><th>Corrigée</th><td>J0 + 2</td><td>J0 + 3</td><td>J0 + 5</td></tr><tr><th>Rejetée</th><td>J0 + 2</td><td>J0 + 3</td><td>J0 + 5</td></tr><tr><th>Fermée</th><td colspan="3">aussitôt après test</td></tr></tbody></table>

Le gestionnaire d'anomalies devra disposer de fonctions d'alertes permettant d'assurer la fluidité du processus de correction.

## 21 Tests et Recettes

La recette regroupe toutes les méthodes mises en œuvre par le titulaire dans l'optique d'améliorer la qualité du SI, que ce soit par des tests de fonctionnalités, des choix techniques (simplification de code, commentaires, etc.) ou même des problématique d'interface.

L'objectif de cette démarche est aussi d'éviter de mettre l'INRA dans une situation où la livraison d'un lot<fnref n="7" /> de développements complet doit se faire en une seule fois. En effet, la pression exercée sur le calendrier de réalisation ne permet pas d'envisager de trop nombreuses opérations de maintenance corrective portant sur des anomalies bloquantes ; il est donc essentiel de détecter au plus tôt ce genre de problèmes.

Les contraintes exprimées sur l'architecture applicative (notamment le fait d'avoir des composants fonctionnels faiblement liés) permettront la pré-vérification des modules fonctionnels avant la livraison d'un lot de développements. Le titulaire fournira à l'INRA un plan de tests adapté à ces modules.

Cette pré-vérification est assurée dans un premier temps par le titulaire (recette fournisseur), puis par l'INRA.

Ces phases de pré-vérification auront lieu sur un environnement mis à disposition par le titulaire.

Lorsque le lot de développements de l'application sera considéré comme testé et validé par le titulaire, l'application :

* sera fonctionnellement validée par l'INRA sur la plate-forme du titulaire,

<footnote n="7">⁷ Lot de développements : ici dans le sens d'une partie de l'ensemble des développements, à ne pas assimiler à la notion d'allotissement des marchés publics.</footnote>
* puis, en début de phase de VA, sera installée sur les serveurs chargés de l'hébergement à l'INRA. L'opération d'installation sera réalisée par l'INRA :

* sur la base des documents et livrables nécessaires au déploiement fournis par le titulaire,

* et sous le contrôle du titulaire.

Suite à la mise en ordre de marche, l'INRA se charge de recruter un panel de testeurs qui sera mobilisé en phase de VA. Cette phase de tests pourra être réalisée avec l'assistance du titulaire.
Cahier 6 : Description des prestations attendues
## 22 Fréquence et types de commande des prestations

<table><caption>Figure 4 : Périmètre d'achat</caption><thead><tr><th>Catégorie de prestation</th><th>Détails</th><th>Fréquence</th><th>Commande</th></tr></thead><tbody><tr><td>Prestations d'entrée</td><td>Prise en main initiale</td><td>1 seule fois</td><td>Forfait</td></tr><tr><td rowspan="4">Développements en mode projet</td><td>Prestation d'avant-projet : cadrage de réalisation du projet</td><td>À la demande</td><td>Bon de commande</td></tr><tr><td>Réalisation des développements du projet</td><td>À la demande</td><td>Bon de commande</td></tr><tr><td>Intégration des réalisations INRA</td><td>À la demande</td><td>Bon de commande</td></tr><tr><td>Mise en place de tests fonctionnels des copier/coller d'interventions réalisées (cas pratique de ce marché)</td><td>1 seule fois, en option</td><td>Forfait</td></tr><tr><td rowspan="2">Prestations complémentaires</td><td>Analyses fonctionnelles et techniques</td><td>Occasionnelle, à la demande</td><td>Bon de commande</td></tr><tr><td>Formation : transfert technique</td><td>Occasionnelle, à la demande</td><td>Forfait</td></tr><tr><td>Prestations de sortie</td><td>Réversibilité de l'application</td><td>1 seule fois, en option</td><td>Forfait</td></tr></tbody></table>

## 23 Conditions d'exécution des prestations

<table><thead><tr><th>Catégorie de prestation</th><th>Règles</th><th>Conditions</th></tr></thead><tbody><tr><td>Prestations d'entrées</td><td>Prise en main initiale</td><td>La prise en main est commandée préalablement à tout développement pour que le titulaire maîtrise la maintenance de l'application</td></tr><tr><td rowspan="2">Développements en mode projet</td><td>Avant-projet, cadrage</td><td>Commande par intervention. Le cadrage de la réalisation du projet n'oblige pas l'INRA à commander sa réalisation.</td></tr><tr><td>Réalisation des développements du projet</td><td>Toute réalisation de développement du projet (comprenant les évolutions et les résolutions d'anomalies</td><td>Commandable éventuellement groupée avec les prestations</td></tr></tbody></table>
<table><caption>Figure 5 : Cadre des règles et des conditions de commande des prestations</caption><tr><td></td><td></td><td>non comprises dans la garantie) est précédée à minima d'un cadrage de la réalisation du projet. Chaque phase nécessite d'être conforme pour lancer la phase suivante (soit suite à déclaration du titulaire ou soit suite à vérification positive).</td><td>d'avant-projet.</td></tr><tr><td rowspan="2">Prestations complémentaires</td><td>Intégration des réalisations INRA</td><td>Certaines réalisations pourront être effectuées par l'INRA. Ceci sera décidé lors de la phase d'avant-projet. Le titulaire sera alors chargé d'encadrer le travail de l'INRA pour qu'il s'intègre parmi ses propres réalisations.</td><td>Commandable de manière individuelle.</td></tr><tr><td>Mise en place de tests fonctionnels des copier/coller d'interventions réalisées</td><td>Développement forfaitaire et optionnel (tranche conditionnelle)</td><td></td></tr><tr><td rowspan="2">Prestations de sortie</td><td>Analyses fonctionnelles et techniques</td><td>Commande par intervention</td><td></td></tr><tr><td>Formation : transfert technique</td><td>Commande par intervention</td><td></td></tr><tr><td></td><td>Transférabilité de l'application</td><td>Commande par intervention</td><td></td></tr></table>

## 24 Description des prestations

Suite à la phase de prise en main initiale, l'application va évoluer par itérations successives dont la durée reste à fixer entre le titulaire et l'INRA. Chaque itération constituant un lot<fnref n="8" /> de développement comprendra une à plusieurs réalisation(s) en mode projet. Une réalisation en mode projet commence par une phase de cadrage menant ou non à sa réalisation (par le titulaire ou l'INRA).

Des prestations complémentaires de type formation ou expertise peuvent également être demandées ponctuellement par l'INRA.

<footnote n="8">⁸ Lot de développements : ici dans le sens d'une partie de l'ensemble des développements, à ne pas assimiler à la notion d'allotissement des marchés publics.</footnote>
## 24.1 Prise en main initiale

### Définition globale de l'activité :

La prise en main initiale correspond à la période de recouvrement et de transfert de connaissance :

- pour le recouvrement, le titulaire est associé progressivement aux développements, les équipes de l'INRA ou le titulaire sortant assurent dégressivement les développements ;

- pour le transfert de connaissance, l'INRA transfère vers le titulaire l'ensemble des connaissances écrites dont il dispose.

Cette étape permet tout d'abord au titulaire :

- d'exprimer les conditions qui sont nécessaires à la bonne réalisation des prestations ;

- de mettre en place l'environnement technologique nécessaire à l'exécution du marché ;

- d'acquérir les connaissances fonctionnelles et techniques nécessaires ;

- de réaliser l'inventaire des composants fonctionnels ;

- d'acquérir, de mettre en place et d'initialiser ses outils de pilotage et de suivi, d'élaborer et de maintenir la documentation nécessaire ;

- d'élaborer un calendrier de prise en charge de l'application en tenant compte du calendrier de l'INRA ;

- le cas échéant, de mettre en place l'environnement de recette de l'application ;

- de mettre en place la forge logicielle de gestion du projet (comprenant un outil de gestion et de suivi des tâches et anomalies) en reprenant le contenu de la forge Redmine hébergée par le titulaire sortant. La forge de l'INRA pourra être utilisée, le titulaire conseillera alors l'INRA dans son paramétrage ;

- mise en place éventuelle des autres outils de communications avec l'INRA (notamment pour intégrer les ou les développeurs INRA dans l'équipe de développement) ;

- de mettre en place le système de gestion de versions en rapatriant les sources depuis l'infrastructure du titulaire sortant. Le SVN de l'INRA pourra être utilisé ;

- de prendre en charge progressivement les prestations ; dans ce cadre, et en cas de stock d'anomalies résiduelles, le titulaire, après en avoir pris connaissance, proposera un plan de résorption de ces anomalies ;

- de rédiger le plan d'assurance qualité (PAQ) en conformité avec les exigences qualité de l'INRA et comprenant l'ensemble des indicateurs de suivi de la qualité ;

- de confirmer la constitution de l'équipe correspondant aux profils proposés dans l'offre du titulaire. Le titulaire présente le profil et les personnes de l'équipe projet chargées d'opérer le présent marché. Un soin tout particulier doit être apporté sur l'adéquation des profils présentés avec les besoins techniques.

### Livrables :

- La liste nominative des personnes constituant l'équipe du titulaire

- Le plan d'assurance qualité (PAQ) du projet tel que défini au § 19

- Le compte-rendu des réunions de transfert
- Les bilans de la prise de connaissance (1 toutes les 2 semaines) comprenant notamment l'évaluation des compétences acquises relatives à l'application, l'estimation du degré d'autonomie, la liste des tâches effectuées éventuellement en collaboration avec l'ancien titulaire par domaine fonctionnel et technique. L'inventaire des documents et modules logiciels ainsi que les remarques ou les réserves du titulaire sur les éléments manquants.

## Prérequis INRA :

Sous réserve de leur disponibilité, l'INRA fournit, en l'état :

- la documentation fonctionnelle et technique de l'application Agrosyst ;

- les sources de l'application Agrosyst ;

- la liste des anomalies connues (répertoriées dans la forge logicielle du titulaire sortant)

- deux réunions d'information (de l'ordre d'une demi-journée à 1 journée) nécessaires à la compréhension de l'application Agrosyst. La modalité de ces réunions reste à définir, elles pourront se faire à Orléans, Dijon ou Nantes suivant le choix de l'INRA après consultation du titulaire.

## 24.2 Développements en mode projet

Les évolutions d'Agrosyst ou les corrections d'anomalies non garanties dans le cadre du présent marché font l'objet d'une démarche projet de développement.

Les spécifications fonctionnelles seront rédigées par l'INRA et évaluées par le titulaire dans le cadre de la phase de cadrage du projet. Le cadrage de la réalisation du projet n'oblige pas l'INRA à commander sa réalisation.

La réalisation des développements du projet est nécessairement précédée d'un cadrage de réalisation du projet.

Certaines réalisations pourront être effectuées par l'INRA (10 à 20 % des développements), ceci sera défini lors de la phase de cadrage. Dans ce cas, le prestataire proposera un devis pour l'intégration des développements faits par l'INRA comprenant l'apport de conseil, une revue de code et des retours aux développeurs INRA les amenant éventuellement à corriger leur code. La maintenance des fonctionnalités développées par l'INRA sera assurée par le titulaire au titre de la garantie.

### 24.2.1 Avant-projet : cadrage de la réalisation du projet

## Définition globale de l'activité :

Préparer le lancement de la réalisation du projet sur la base des spécifications fonctionnelles et/ou techniques fournies par l'INRA.

- Définir les éléments constitutifs du projet ainsi que les modalités et le dispositif de réalisation :

- le contenu fonctionnel du projet ;

- les solutions technologiques à réaliser ;

- les unités d'œuvre à prévoir ;
- Réaliser l'étude de cadrage proprement dite, généralement structurée sur les axes suivants :

- un retour sur la formalisation des besoins fonctionnels retenus dans le développement afin que l'INRA puisse rédiger les spécifications détaillées ;

- la sélection des technologies et des principes techniques de réalisation ;

- une veille de sécurité et d'obsolescence. Le titulaire est notamment tenu d'informer l'INRA des failles de sécurité présentes dans son application et de proposer des solutions ;

- les activités et actions pour mener à bien le projet ;

- les moyens et équipements (plates-formes de vérification, de formation, ...);

- la stratégie de reprise des données incluant des contrôles ;

- l'étude des impacts sur les autres volets de l'application ;

- Réaliser, conjointement avec l'équipe projet INRA, la définition de la stratégie de test portant sur :

- les tests fonctionnels ;

- les tests techniques ;

- éventuellement les tests de performance.

- Élaborer :

- les délais de mise en œuvre ;

- le budget à prévoir ;

- le planning prévisionnel en durée et délais.

- Positionner les jalons de la réalisation des spécifications détaillées.

### Livrables :

- Etude de cadrage ;

- Le cas échéant, les comptes-rendus de réunion ;

- Le cas échéant, les maquettes et les diagrammes UML ayant servi à affiner le besoin ;

- Stratégie de test ;

- Stratégie de reprise de l' existant incluant des contrôles ;

- Planning de réalisation prévisionnel avec jalons ;

- Devis de la réalisation du projet et du déploiement des sites et licences éventuelles ;

- Ou devis de l'intégration des développements INRA si la réalisation est effectué par l'équipe INRA ;

### Prérequis INRA :

L'INRA fournit :

- Les produits de la phase de rédaction des spécifications fonctionnelles générales ;

- Son intention de réaliser ou non par ses propres moyens les développements et le niveau de reviewing par le titulaire désiré (dépendant du couplage avec les développements réalisés par le titulaire) ;

- Le planning des disponibilités de l'équipe INRA durant la réalisation du projet.

## 24.2.2 Réalisation du projet

### Définition globale de l'activité :
Le titulaire réalise le projet sur la base du devis de la réalisation du projet décrite dans le chapitre 24.2.1.

Les activités à réaliser sont :

- Conceptions techniques détaillées décrivant :

- l'architecture logicielle et technique

- les environnements de qualification, d'exploitation ;

- les contraintes d'intégration avec les produits logiciels de base ;

- les contraintes d'interfaçage avec les autres produits ;

- les attentes en termes d'exploitabilité ;

- les performances attendues et le niveau de service requis (capacité fonctionnelle, fiabilité, facilité d'utilisation, rendement, maintenabilité) ;

- Spécifications des développements complémentaires, des paramétrages, initialisation, reprise de l'existant ;

- Veille de sécurité ;

- Élaboration des scénarii fonctionnels et techniques de tests ou éventuellement des tests de performance ;

- Reprise des données en respectant les jalons de contrôle ;

- Développement du projet ;

- Gestion des versions des composants et de l'application ;

- Intégration du projet ;

- Réalisation de la recette fournisseur sur la base du plan de tests ;

- Formation de l'INRA à l'utilisation des nouvelles fonctionnalités ;

- Support lors des opérations de vérification ;

- Traitements des non conformités détectées au cours des opérations de vérification.

- Une assistance technique en cas de difficulté de mise en production.

## Livrables :

- Le cas échéant, les maquettes d'IHM ;

- Le cas échéant, les comptes-rendus de réunion ;

- Dossier de spécifications techniques détaillées (STD) ;

- Cahier de tests et résultat des tests portant sur :

- les tests fonctionnels ;

- les tests techniques avec les contrôles de non régression ;

- éventuellement les tests de performance.

- Documentation de suivi de chaque évolution et correction, détaillant l'anomalie constatée et l'ensemble des travaux réalisés, reprise sous forme de commentaire dans chaque source ;

- Liste des fonctionnalités ayant fait l'objet de revue de code ;

- Paquet logiciel (exécutable et code source) et procédure de déploiement sur les différents environnements décrits au 15 ;

- Mise à jour du référentiel documentaire du projet (spécifications fonctionnelles et techniques, documents utilisateurs, dossier d'architecture, d'exploitation, d'installation, de paramétrage, de tests, les Frameworks et les patterns utilisés, procédures et scripts d'installation et d'exploitation, diagrammes UML...)

- Une description complète du contenu de la livraison (release notes) ;

- Documentation
- PV de validation de ces différents documents ;

### Prérequis INRA :

L'INRA fournit :

- le dossier de spécifications fonctionnelles détaillées (SFD) décrivant :

- les besoins métiers, les priorités en regard de la stratégie et de l'organisation

- les fonctionnalités à mettre en œuvre, les données et règles de gestion

- les modèles conceptuels des données, les traitements

- les groupements fonctionnels

- les interfaces fonctionnelles vis à vis des autres domaines, et les règles de gestion

- les modalités fonctionnelles de reprise de l'existant

- les travaux et documents existants ;

- les précisions et détails sur les périmètres fonctionnels et techniques ;

- la présentation des normes, chartes, méthodes, politiques et outils utilisés ou en vigueur au sein de l'organisme bénéficiaire et/ou au ministère.

Tout au long de cette phase, l'équipe projet INRA sera disponible pour répondre aux questions, pour émettre des observations sur les livrables de l'activité et pour tester les réalisations au fur et à mesure des développements.

### 24.2.3 Intégration des réalisations INRA

Comme indiqué au chapitre 24.2 (24.2 Développements en mode projet) certaines réalisations pourront être effectuées par l'INRA (10 à 20 % des développements), ceci sera défini lors de la phase de cadrage de chaque projet. Les développements INRA s'inscriront pleinement dans un lot de développement réalisé, à l'occasion, conjointement par l'INRA et le titulaire, les phases post-développement (pré-vérifications, vérifications etc.) s'appliqueront de la même manière à l'ensemble du lot.

#### Définition globale de l'activité :

Le prestataire encadre les développements réalisés par l'INRA. Il effectue :

- Une réponse écrite aux questions techniques de l'INRA ;

- La revue du code (le taux de relecture dépendra du couplage avec les développements réalisés par le titulaire) ;

- La validation des livrables INRA ;

- L'intégration de ces développements au lot de développement en cours de réalisation.

#### Livrables :

- Listing des retours faits à l'INRA suite à la revue de code ;

- Le cas échéant, les comptes-rendus de réunion ;

- Paquet logiciel (exécutable) et procédure de déploiement sur les différents environnements décrits au § 15 ;

- PV de validation de ces documents.

L'INRA prendra alors à sa charge la réalisation des autres livrables décrit au chapitre 24.2.2 (Réalisation du projet), et les mettra à disposition du titulaire.
**Prérequis INRA :**

Les prérequis sont ceux définis au chapitre 24.2.2 (Réalisation du projet).

### 24.2.4 Tests fonctionnels des copier/coller d'interventions réalisées (cas pratique)

Il est rappelé que cette prestation constitue une tranche conditionnelle de la consultation.

**Définition globale de l'activité :**

Le titulaire réalise, en mode projet, la mise en place de tests fonctionnels des copier/coller d'interventions réalisées sur Agrosyst. En se basant sur la documentation fournie pour le cas pratique de cet appel d'offre, la prestation inclura :

- la phase de cadrage définie au § 24.2.1

- la réalisation des développements telle que défini au § 24.2.2

Le candidat devra fournir, dans sa réponse, les éléments techniques et le chiffrage demandés dans le document **Description_Cas_Pratique_Agrosyst.pdf** définissant ce cas pratique.

**Livrables :**

Les livrables sont ceux décrits aux § 24.2.1 et 24.2.2, à l'exception des devis de réalisation, puisque cette prestation est forfaitaire.

**Prérequis INRA :**

Les prérequis INRA sont ceux décrits aux § 24.2.1 et 24.2.2.

## 24.3 Services et prestations complémentaires

### 24.3.1 Analyses fonctionnelles et techniques

**Définition globale de l'activité :**

Cette activité regroupe des analyses comme (liste non exhaustive) :

- l'analyse complémentaire préalable à la correction d'une anomalie (cas d'anomalies complexes);

- l'analyse d'impacts d'une demande d'évolution (évolutions complexes);

- l'analyse des performances d'une application, selon un scénario défini;

- tout autre type de demande d'expertise.

**Livrables :**

- Compte rendu d'intervention avec plan d'action de résolution;

- Le cas échéant, les comptes-rendus de réunion;

- Un dossier d'analyse comportant notamment :

- l'avis du titulaire sur les nouvelles versions des outils ou des composants,
* le calendrier des travaux,

* la méthode d'optimisation,

* la mesure des impacts sur les applications,

* la garantie de migration à l'identique en terme de fonctionnalité utilisateur,

* la garantie de non-régression des performances,

* la présentation des impacts sur les outils et traitements connexes aux applications,

* la stratégie de mise à jour de l'ensemble de la documentation du produit,

* la stratégie de tests d'intégration et de non-régression et de performances,

* les comptes rendus des réunions de travail avec les équipes de l'Onema,

* une estimation du coût de la mise en œuvre.

### Prérequis INRA :

L'INRA fournit au titulaire toute information jugée nécessaire pour la bonne réalisation de cette étude. Cette information pourra être de type :

- cahier des charges ;

- fiche d'incident ou d'anomalie ;

- scénario d'utilisation ;

- ...

## 24.3.2 Formation : transfert technique

### Définition globale de l'activité :

L'INRA pourra demander au titulaire de réaliser une formation pour son personnel en charge de développer Agrosyst.

Cette formation sera assurée pour une à trois personnes et pourra être réalisée dans les locaux de l'INRA (Orléans) ou du prestataire, selon le choix du candidat.

Un forfait sur une durée de 3 jours est demandé.

La formation portera sur :

* l'architecture applicative,

* les relations entre les composants métier, les services

* les frameworks et les patterns utilisés,

* la gestion de la persistance des données,

* l'ensemble des outils et objets à maintenir,

* la documentation associée,

* les différents environnements,

* les outils de la maintenance,

* les dispositifs de surveillance de fonctionnement de l'application

* les procédures en place et le dispositif de livraison et d'installation de l'application ;

Suite à cette formation, les personnes devront être capables de savoir sur quel composant ou quel objet intervenir pour modifier une fonction du système, ajouter une variable dans une entité en intervenant sur la base et l'interface utilisateur, etc.

Le contenu pourra cependant être modulable pour porter sur un aspect technique en particulier.
Il n'est pas demandé au titulaire d'inclure dans la formation un apprentissage détaillé des Framework et composants open source utilisés.

**Livrables :**

- Supports de formation ;

- Feuille de présence à la formation ;

**Prérequis INRA :**

L'INRA informe le prestataire de son intention d'avoir une formation ainsi que les points que son équipe souhaite étudier plus particulièrement.

## 24.4 Réversibilité

**Définition globale de l'activité :**

La réversibilité concerne notamment le processus de transfert des données et des documents, commandés au titulaire, en fonction des standards ou normes, en vigueur à la date du lancement de la réversibilité.

Le titulaire fournit au minimum :

- l'établissement d'un plan de réversibilité décrivant les travaux et livrables des trois parties en présence (INRA, titulaire sortant, titulaire entrant) ;

- la mise à niveau et la livraison de l'ensemble de la documentation ;

- une présentation au nouveau titulaire et à l'INRA sur :

- l'architecture applicative,

- l'ensemble des outils et objets à maintenir,

- la documentation associée,

- les différents environnements,

- les outils de la maintenance,

- les principales procédures en place et le dispositif de livraison ;

- la fourniture d'une assistance technique auprès du nouveau titulaire pour les spécifications et la réalisation des prestations de maintenance standard sous sa responsabilité lors du dernier mois de la phase.

Le titulaire prend à sa charge le transfert de compétence fonctionnel à destination de l'éventuel nouveau titulaire.

Ce transfert de connaissance se déroulera en parallèle des prestations déjà en cours ou planifiées sur la période correspondante.

La durée de la phase de réversibilité n'excédera pas 2 mois. Le dernier mois sera une période de recouvrement pendant laquelle le nouveau titulaire du nouveau marché sera associé à la maintenance, le titulaire du présent marché restera pleinement responsable au titre de son obligation de résultats qui court jusqu'à la fin de la garantie du présent marché.

**Livrables :**

- Plan de réversibilité ;

- Support de formation au nouveau titulaire ;

- Code sources ;

- Ensemble de la documentation à jour
- Attestation d'assistance technique

### Prérequis INRA :

L'INRA informe le titulaire de la date de déclenchement de la phase de réversibilité, et du déclenchement de la prestation correspondante.

## 24.5 Définition des indicateurs

La qualité des livrables ou des prestations s'évalue sur la base de huit facteurs qualité :

* La non-régression ;

* La maintenabilité ;

* L'ergonomie ;

* La fiabilité ;

* La documentation ;

* Les performances ;

* La sécurité.

Les indicateurs relatifs à ces différents facteurs seront proposés par le titulaire dans le PAQ et validés par l'INRA.

## 25 Développements prévisibles

À la date de publication de ce document, les prochains développements figurant sur la feuille de route d'Agrosyst sont les suivants :

- Enrichissement de la gamme d'indicateurs avec les **indicateurs agronomiques et environnementaux** ;

- Intégration d'éléments utiles à la vie du réseau DEPHY : nouveau formulaire de saisie permettant la saisie du **bilan de campagne** ;

- **Amélioration du menu « Performances »** afin qu'il soit plus intuitif et ergonomique et que les indicateurs soient calculés rapidement ;

- Calcul de l'IFT : les doses de référence et l'information sur le biocontrôle seront récupérées par le biais d'une API (adaptation à la nouvelle méthode définie par le ministère) ;

- Autres **améliorations ergonomiques** : création d'un « local » virtuel d'intrants pour chaque exploitation, amélioration des modalités de saisies des doses en arboriculture, suppression d'entités, aide à la vérification des données, diminution du temps d'affichage de certains menus (contexte de navigation, domaines, actes synthétisés) etc. ;

- Mise en place d'un module de **requêtage pour l'extraction de données** ;

- Export de **bilans** : fiches descriptives de système de culture, positionnement d'un système par rapport aux données de référence, etc.

- **Interopérabilité** : début de mise en place de l'export de données au format eDaplos ;

- **Maintenance** : corrections de bugs éventuels, évolution des référentiels, maintenance des serveurs.

Cette liste de fonctionnalités est donnée à titre indicatif aux candidats, l'INRA ne s'engage pas à demander leur réalisation dans le cadre de ce marché.
Cahier 7 : Mise en œuvre par le
titulaire
## 26 Organisation du titulaire

Lors de l'initialisation du marché, le titulaire désigne un directeur de projet et met en place une équipe projet.

En cas de changement du directeur de projet, un tuilage de 5 jours ouvrés doit être prévu pour permettre le transfert de connaissances.

Tout changement prévu dans l'équipe projet du titulaire devra être notifié par écrit à l'INRA, 15 jours à l'avance. L'INRA dispose alors de 5 jours ouvrés pour vérification des compétences du nouveau membre de l'équipe lui permettant de l'accepter ou de le refuser.

Le titulaire est responsable de la formation de son personnel sur l'ensemble des sujets relevant des prestations demandées. Il en assume le cout et l'incidence sur l'organisation de la prestation.

De tels changements de personnes ne modifient pas les délais de réalisation des livrables acceptés par le titulaire.

Ponctuellement l'INRA pourra demander qu'un expert technique du titulaire fasse une revue de code.

## 27 Périodes et délais

Les jalons s'entendent comme la date de fin de l'étape indiquée. La validation de ces jalons est nécessaire au passage de l'étape suivante, et conditionne le départ du délai pour ces étapes.

Les attentes en évolution d'Agrosyst étant importantes, la **phase de prise en main initiale** devra **commencer dans les 15 jours suivant la signature du marché**. Les développements en mode projet commenceront dès la fin de cette phase de prise en main.
## 27.1 Prise en main initiale

<table><thead><tr><th rowspan="2">Action projet</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td>Commande</td><td>Date de réception de commande</td><td>T<sub>0</sub></td><td></td><td></td></tr><tr><td>Liste nominative des personnes constituant l'équipe du titulaire</td><td></td><td></td><td>T<sub>0</sub> + 10 jours</td><td></td></tr><tr><td>Le plan d'assurance qualité (PAQ)</td><td></td><td></td><td>T<sub>0</sub> + 15 jours</td><td></td></tr><tr><td>Bilans de la prise de connaissance</td><td></td><td></td><td>T<sub>0</sub> + 15 jours puis tous les 15 jours</td><td></td></tr><tr><td>Capacité à assurer seul les développements en mode projet</td><td></td><td></td><td>T<sub>0</sub> + 2 mois</td><td></td></tr></tbody></table>

## 27.2 Développements en mode projet

### 27.2.1 Avant-projet

Les délais de livraison des études de cadrage de réalisation sont fixés à la commande en accord avec le titulaire. Sauf accord ou demande explicite de l'INRA, le délai de réalisation d'une commande d'avant-projet ne pourra pas excéder 1 mois (débutant à la commande de l'INRA).

### 27.2.2 Réalisation du projet

Le démarrage de la réalisation du projet et les délais de livraisons sont fixés lors du cadrage par l'INRA en accord avec le titulaire, après planification des travaux par ce dernier.

Sauf accord ou demande explicite de l'INRA, le délai entre la fin de la phase de cadrage (date du devis) et le début de la réalisation ne pourra pas dépasser 1 mois.

<table><thead><tr><th rowspan="2">Action projet</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td>SFD</td><td>Fourniture par l'INRA des SFD</td><td>T<sub>0</sub></td><td></td><td></td></tr><tr><td>Validation des SFD</td><td>Validation par le titulaire des SFD</td><td>T<sub>1</sub></td><td>T<sub>0</sub> + 7 jours</td><td></td></tr><tr><td>Réalisation des STD</td><td>Fourniture des STD par le titulaire</td><td>T<sub>2</sub></td><td>T<sub>1</sub> + 7 jours</td><td></td></tr><tr><td>Validation du STD</td><td>Par l'INRA</td><td>T<sub>3</sub></td><td></td><td>T<sub>2</sub> + 7 jours</td></tr><tr><td>Fourniture des cahiers de tests</td><td></td><td>T<sub>4</sub></td><td colspan="2">Délai fixé dans le cadrage de la réalisation</td></tr></tbody></table>
<table><tr><td>Validation des cahiers de tests</td><td>Par l'INRA</td><td>T<sub>5</sub></td><td>T<sub>4</sub> + 7 jours</td></tr><tr><td>Début des développements</td><td></td><td>T<sub>6</sub></td><td>T<sub>5</sub></td></tr><tr><td>Pré-vérifications</td><td>Déploiement de l'environnement par le titulaire</td><td>T<sub>7</sub></td><td>T<sub>6</sub> + 7 jours puis toutes les semaines</td></tr><tr><td>Pré-vérifications : validation</td><td>Vérification par l'INRA</td><td></td><td>T<sub>7</sub> + 7 jours</td></tr><tr><td>Fin des développements, fourniture des résultats de tests, fourniture du paquet logiciel</td><td></td><td>T<sub>MOM</sub></td><td>Délai fixé dans le cadrage de la réalisation</td></tr><tr><td>Vérifications</td><td>Réalisation des opérations de vérification et garantie et modifications éventuelles du paquet logiciel</td><td></td><td>Cf délais opérations de vérifications et garanties</td></tr><tr><td>Livraison livrable documentaire pour le déploiement INRA</td><td>Assistance à la mise en production</td><td></td><td>Défini au moment de la MOM</td></tr></table>

### 27.2.3 Intégration des réalisations INRA

<table><thead><tr><th rowspan="2">Action projet</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td>Toutes</td><td>Réponses aux questions de l'INRA</td><td></td><td>T + 7 jours</td><td></td></tr><tr><td>Revue de code</td><td></td><td></td><td>T + 2 semaines après demande de l'INRA</td><td></td></tr><tr><td>Fourniture du paquet logiciel</td><td></td><td>T<sub>MOM</sub></td><td>Délai fixé dans le cadrage de la réalisation</td><td></td></tr><tr><td>Validation documentaire</td><td>Par le titulaire</td><td></td><td>Défini au moment de la MOM</td><td></td></tr></tbody></table>
### 27.2.4 Opérations de vérification et garantie

<table><thead><tr><th colspan="2">Action de gestion</th><th rowspan="2">Détails</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>N°</th><th>Intitulé</th><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td rowspan="3">1</td><td rowspan="3">Vérification d'aptitude (VA)</td><td>Tests de VA + vérifications livrables</td><td>Décision de VA<br/>> VA positive (T<sub>VA</sub>)<br/>> Ajournement (T<sub>ajournement</sub>)<br/>> rejet</td><td>T<sub>ajournement</sub><br/>ou T<sub>VA</sub></td><td>T<sub>MOM</sub> + 30<br/>jours</td></tr><tr><td>En cas d'ajournement</td><td>Corrections du titulaire et nouvelle MOM</td><td>T<sub>Nouvelle MOM</sub></td><td>T<sub>ajournement</sub> + 5 jours</td></tr><tr><td>Nouveaux tests de VA suite à ajournement</td><td>Décision de VA<br/>> VA positive (T<sub>VA</sub>)<br/>> Ajournement (T<sub>ajournement</sub>)<br/>> rejet</td><td>T<sub>nouvel ajournement</sub><br/>ou T<sub>VA</sub></td><td>T<sub>MOM</sub> + 5<br/>jours</td></tr></tbody></table>

Suite à un nouvel ajournement, les délais appliqués correspondent à ceux d'une nouvelle MOM de VA.

<table><thead><tr><th colspan="2">Action de gestion</th><th rowspan="2">Détails</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>N°</th><th>Intitulé</th><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td rowspan="3">2</td><td rowspan="3">Vérification de services réguliers (VSR)</td><td>Vérifications disponibilités + vérification livrable de mise en production</td><td>Décision de VSR<br/>> VSR positive<br/>> Ajournement<br/>> Rejet</td><td>T<sub>ajournement</sub><br/>ou T<sub>VSR</sub></td><td>T<sub>VA</sub> + 2 mois</td></tr><tr><td>En cas d'ajournement</td><td>Corrections du titulaire et nouvelle MOM</td><td>T<sub>Nouvelle MOM VSR</sub></td><td>T<sub>ajournement</sub> + 5 jours</td></tr><tr><td>Nouveaux tests de VSR suite à ajournement</td><td>Décision de VSR<br/>> VSR positive<br/>> Ajournement<br/>> Rejet</td><td>T<sub>nouvel ajournement</sub><br/>ou T<sub>VSR</sub></td><td>T<sub>MOM VSR</sub> + 5<br/>jours</td></tr><tr><td>3</td><td>Période de garantie</td><td></td><td></td><td></td><td>T<sub>VSR</sub> + 1 an</td></tr></tbody></table>

Suite à un nouvel ajournement, les délais appliqués correspondent à ceux d'une nouvelle MOM de VSR.
### 27.2.5 Formation : transfert technique

<table><thead><tr><th rowspan="2">Action projet</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td>Commande</td><td>Date d'envoi du bon de commande</td><td>T<sub>0</sub></td><td></td><td></td></tr><tr><td>Formation</td><td></td><td></td><td colspan="2">T<sub>0</sub> + 1 mois (max)</td></tr></tbody></table>

### 27.2.6 Réversibilité

<table><thead><tr><th rowspan="2">Action projet</th><th rowspan="2">Évènements</th><th rowspan="2">Jalons</th><th colspan="2">Délais maximum</th></tr><tr><th>Titulaire</th><th>INRA</th></tr></thead><tbody><tr><td>Commande</td><td>Date d'envoi du bon de commande</td><td>T<sub>0</sub></td><td></td><td></td></tr><tr><td></td><td>Début de phase</td><td></td><td>T<sub>0</sub> + 8 jours</td><td></td></tr><tr><td>Livraison</td><td></td><td></td><td>T<sub>0</sub> + 2 mois</td><td></td></tr></tbody></table>
# 28 Développements en mode projet

## 28.1 Cadrage de la réalisation du projet

### 28.1.1 Chiffrage de la phase de cadrage

Le candidat proposera une méthode d'évaluation des unités d'œuvre (UO) de cadrage dépendant de la complexité de l'évolution demandée.

### 28.1.2 Détermination des délais de livraison

Les délais de livraisons sont fixés lors du cadrage par l'INRA en accord avec le titulaire, après planification des travaux par ce dernier.

### 28.1.3 Chiffrage des évolutions

Le chiffrage des UO de réalisation de projet est dépendant du niveau de complexité des évolutions.

<table><thead><tr><td>Niveau</td><td>Critères</td></tr></thead><tbody><tr><td>Simple</td><td>Modification des éléments de présentation (écran ou état)<br/>Pas de modification de règles de gestion<br/>Pas de modification de structure de données</td></tr><tr><td>Standard</td><td>Modification ou ajout d'éléments de présentation (écran ou état)<br/>Modification ou ajout de règles de gestion élémentaires à impact local<br/>Modification légère de la base de données :<br/>ajout colonnes d'attribut,<br/>modification des formats de champs</td></tr><tr><td>Complexe</td><td>Modification ou ajout d'éléments de présentation (écran ou état)<br/>Modification ou ajout de règles de gestion imbriquées à impact diffus<br/>Modification lourde de la base de données :<br/>ajustement des cardinalités,<br/>ajout de tables,<br/>création d'un script de migration des données</td></tr><tr><td>Très complexe</td><td>Modification ou ajout d'éléments de présentation (écran ou état)<br/>Modification ou ajout de règles de gestion imbriquées à impact diffus<br/>Restructuration partielle de la base de données :<br/>modifications multiples des cardinalités ;<br/>ajout multiple de tables</td></tr></tbody></table>

Le titulaire propose dans son offre une méthode d'évaluation des UO de développement, prenant en compte le critère de complexité, en terme de :

* Coût de réalisation ;

* Délai de réalisation ;

* Délai de recette.
Lorsque plusieurs demandes d'évolutions semblables sont faites, la méthode proposée doit tenir compte d'un taux de réutilisabilité d'une évolution.

L'INRA doit être en mesure de pouvoir faire les évaluations et donc disposer de tous les outils nécessaires. Pour cela, le titulaire assure un transfert de connaissances vers l'équipe projet.

### 28.1.4 Chiffrage de l'intégration des réalisations Inra

Selon la même méthodologie que pour le chiffrage des UO de réalisation, le candidat proposera un chiffrage des UO d'intégration des développements Inra.

Il est rappelé que la maintenance des fonctionnalités développées par l'INRA sera assurée par le titulaire au titre de la garantie.

## 28.2 Mise en œuvre de la réalisation du projet

La mise en œuvre de la réalisation de projet comprend les étapes suivantes, définies dans le CCAP :

* La Mise en Ordre de Marche (MOM) dans un environnement de qualification de l'INRA ;

* La Vérification d'Aptitude (VA) ;

* La Vérification de Service Régulier (VSR) ;

* Une période de garantie.

## 29 Sécurité du système d'information

Le niveau de sécurité est fortement dépendant des enjeux du système développé. Les principaux domaines concernés sont :

* disponibilité, intégrité des données, niveau de confidentialité des informations en fonction de leurs sensibilités,

* authentification

* traçabilité

Les données sensibles sont constituées des données personnelles des agriculteurs et des mails des utilisateurs.

D'une manière générale, le prestataire sera vigilant à respecter les bonnes pratiques en termes de développement et d'architecture afin d'éviter des malveillances externes.

Le titulaire reprendra le mécanisme d'authentification existant (HTTP/SSL - login / mot de passe crypté).

L'INRA pourra réaliser des tests de sécurité des applications développées afin de vérifier que les développements ne contiennent pas des failles de sécurité. Dans le cas où une faille est découverte, le prestataire est dans l'obligation de mettre en œuvre un correctif avant la mise en production ou, si accord de l'INRA d'assurer une mise à jour de la production dans un délai raisonnable.

### 29.1 Obligation en termes de sécurité
Le titulaire est tenu d'informer l'INRA des alertes de sécurité et d'obsolescence des composants.

Des sites comme celui du CERT-FR (Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques) ou de l'OWASP (Open Web Application Security Project) pour la lutte contre les causes d'insécurité (http://www.owasp.org) font référence.

## 29.2 Confidentialité

Les règles de confidentialité sont décrites dans le CCAP.

## 29.3 Sauvegarde

Le titulaire est responsable de la sauvegarde des sources de l'application et de l'ensemble du référentiel documentaire dans le cas où son environnement est utilisé pour le projet. Il n'est pas responsable des sauvegardes des données et des versions en production.
Cahier 9 : Annexes
## 30 Liste des annexes

* Dossier « Cas pratique » comprenant le guide utilisateur

## 31 Glossaire des abréviations

**CAN** Cellule d'Animation Nationale du réseau DEPHY

**DEPHY** réseau de Démonstration, Expérimentation et Production de références sur les systèmes économies en phytosanitaires

**IR** Ingénieur Réseau

**IT** Ingénieur Territorial

**MAAF** Ministère de l'Agriculture, de l'Agroalimentaire et de la Forêt

**MOM** Mise en Ordre de Marche

**PSPE** Projet Pour et Sur le Plan Ecophyto

**RDD** Règles De Décisions

**SdC** Système de Culture

**SFD** Spécifications Fonctionnelles Détaillées

**SFG** Spécifications Fonctionnelles Générales

**STD** Spécifications Techniques Détaillées

**UO** Unité d'Œuvre

## 32 Auteurs

Estelle ANCELET et Antoine SCHELLENBERGER – US Infosol Orléans, Inra

Morgane DUBUC, Ophélie JOLYS et Nicolas MUNIER-JOLAIN – UMR Agroécologie Dijon, Inra