1. cahier des charges - m.behe.free.frm.behe.free.fr/cours/l3/semestre_5/sie/tp/cdc_exemple.pdf ·...

Cours SIE : CdC et AO 1

Version 2005.07 © P.Nasarre

1. Cahier des charges

Le présent document est un exemple de cahier des charges réalisé pour le compte d’un grand groupe français du secteur des Fruits et Légumes. Ce cahier est issu d’un CdC authentique et permet d’avoir une première approche, certes incomplète, mais suffisante de ce type de document. Afin de préserver l’anonymat de la société réelle, tous les noms et toutes les références ont été volontairement modifiés. La version ci-après est la version quasi-finalisée à l’issue de son appel d’offre réalisée par cette société. La version finalisée étant trop lourde n’a pas été présentée ici. On n’a pas non plus ajouté les annexes (qui représentent 40 pages supplémentaires), ni le contrat. Le présent CdC (qui va du chapitre 2 à 8) est suivi d’exemples de tables des matières d’un cahier des charges type et d’un cahier des charges logiciel.



2. Cadre

Le présent cahier des charges se place dans le cadre de l’informatisation des échanges au sein du groupe LALLIER-Fruits. Il concerne le système informatique permettant la mise en œuvre de l’échange des mercuriales ainsi que la consolidation des statistiques.

2.12.12.12.1 Présentation générale de LALLIERPrésentation générale de LALLIERPrésentation générale de LALLIERPrésentation générale de LALLIER

2.1.1 Historique Le groupe LALLIER est né en 1974, du constat que le maillon distributeur au stade de gros dans la filière Fruits et Légumes était alors trop atomisée et la taille des entreprises insuffisante pour s’adapter efficacement à l’évolution déjà rapide du marché. Ainsi LALLIER a fédéré, au fil des ans, des entreprises opérant en «service complet » et pour la plupart dotées de moyens logistiques modernes. Le groupe dispose aujourd’hui d’une couverture géographique nationale au travers d’une trentaine d’entreprises régionales et d’une cinquantaine de plates-formes de distribution. LALLIER est également doté d’une organisation en amont. Ses structures d’achat sont implantées dans les grands bassins de production et/ou à l’import des grandes origines, le groupe mène une politique active de contractualisation de ses relations avec la production. Création unique (le seul groupement de ce type en Europe avec Fxxxxx en Allemagne) et originale (des indépendants mettant en commun leur savoir faire et leurs moyens financiers pour mener ensemble des actions collectives), LALLIER est aujourd’hui le troisième distributeur français de fruits et légumes au stade de gros avec un volume annuel de près de 400 000 tonnes et un CA de plus de 2,5 milliards de francs.

2.1.2 Structures et organisation La coopérative LALLIER SA fédère les adhérents et fixe les règles du jeu au sein du groupe dont la SA LALLIER FRUITS est la structure opérationnelle.

2.1.2.1 LALLIER-SA Société anonyme à forme coopérative et à capital variable, LALLIER SA est la structure juridique d’accueil des Adhérents. LALLIER SA définit les grandes orientations du groupe ainsi que son règlement intérieur, véritable charte garante de la cohésion de LALLIER. N’ayant aucune activité commerciale en propre, LALLIER SA bénéficie d’un contrat avec la SA LALLIER-Fruits qui est la véritable structure opérationnelle du Groupe.

2.1.2.2 LALLIER-FRUITS Chaque adhérent1 de LALLIER est individuellement lié à la SA LALLIER-Fruits par un contrat d’affiliation qui explicite en particulier les obligations contractuelles des parties vis à vis des fournisseurs et des clients du Groupe. LALLIER-Fruits est une société anonyme à directoire et à conseil de surveillance dont le capital est détenu par les adhérents et qui met en œuvre la totalité des moyens financiers, techniques et humains nécessaires pour le bon fonctionnement du groupe. Les activités commerciales que développe le Groupe, tant en amont qu’en aval, relèvent des attributions de LALLIER-Fruits. 1 Que l’on nommera « Partenaires »



2.1.3 L’action de LALLIER 2.1.3.1 Objectif général

« Chaque jour à l’écoute de nos marchés, proposer à nos clients la solution Fruits et Légumes [F&L] adaptée à leurs besoins, dans une double dynamique de développement et de productivité » LALLIER est un réseau organisé, en amont comme en aval, de spécialistes multi-circuits, nous mettons en œuvre une politique commerciale en direction de la grande et moyenne surface [GMS], du commerce de proximité, des spécialistes et traditionnels, de la restauration hors foyer [RHF] ou encore des « cash & carry ».

2.1.3.2 Intervention Elle est orientée en priorité vers trois types d’actions, respectivement tournées vers les achats, la vente et les services :

� Acheter de manière compétitive Cette mission impose tout à la fois :

• Une sélection stricte des origines, des fournisseurs et des produits traités • De s’appuyer sur des structures adaptées aux spécificités de la production

ou de l’origine ainsi qu’aux volumes traités � Adapter nos services pour développer les ventes de nos clients

Nos clients et prospects sont des organisations nationales ou multi-régionales. La nature des contrats que nous initions peut notamment engager :

• Des prestations de services spécifiques • Des référencements de fournisseurs et des assortiments adaptés • Des définitions d’organisation personnalisées [regroupement régionaux à la

carte, tarification, facturation, informatique , …] � Aider notre réseau à améliorer ses performances

Dans le prolongement de ses engagements amont et aval, LALLIER intervient dans :

• La formation : les budgets de formation des Partenaires sont mutualisés • La coordination de choix et investissements : EDI, équipements, … • Économies d’échelles : TFSE, assurances, assurance crédit, manutention,

…. 2.1.3.3 Valeurs

Fédérées sur leurs objectifs et le double niveau de leurs engagements amont et aval, l’implication de nos équipes est également le fruit de valeurs partagées :

• Passion quotidienne : comprendre nos clients et les servir • Philosophie commune : partager nos savoir-faire et innover • Dynamique inépuisable : motiver nos équipes et les former

2.1.4 Organisation de LALLIER-Fruits L’organigramme fonctionnel [simplifié] de la société est actuellement le suivant :



SociedadLallier España

Autres sociétésdu groupe

AssistanteAdministrative

GestionClients

GestionPaie

GestionLallier SA

BanquesFact. Centralisée

Facturationcentralisée

CentralisationPaiement

DirectionAdministrative

DirectionApprovisionnements

DirectionGrands Comptes

Bureau AchatChâteaurenard

Import ItalieChâteaurenard

Bureau AchatPerpignan

Bureau AchatAgen

Bureau ExpéditonValence

Bureau AchatDieppe

Import MarocOutre-Mer

DirectionCommerciale

Import EspagneLerrida

Bureauxrégionaux [3]

BureauxAssociés

PrésidenceLallier-Fruits

2.22.22.22.2 Définition dDéfinition dDéfinition dDéfinition des projetses projetses projetses projets

Les projets consistent d’une part au traitement des mercuriales (Projet dit Mercuriales) et, d’autre part, aux traitements des statistiques de vente (au sein du groupe) par la consolidation des factures des partenaires (Projet dit Conso-Stat).

2.2.1 Nature des échanges Mercuriales Une mercuriale étant définie comme le résultat d’une négociation entre un Partenaires et un client. Les mercuriales sont de deux types :

• Mercuriales client : elles donnent les prix de vente hors taxe par produit à l’issue d’une négociation

• Mercuriales fournisseur : elles donnent les prix d’achat hors taxe par produit à l’issue d’une négociation et serviront à définir une « BOURSE »

Dans cette optique d’échanges, il a été décidé de mettre en œuvre un projet à 2 axes :

A. « Mercuriales clients » comprenant : • la création et la gestion d’une mercuriale, • le traitement statistique des mercuriales (compilation).

� « Mercuriales fournisseurs » comprenant : • la création et la gestion d’une mercuriale, • la compilation des mercuriales pour élaborer les données de la bourse.

2.2.2 Nature des consolidations et statistiques [CO NSO-STAT] Chaque partenaires est utilisateur d’un outil EDI et génère des factures auprès de ses clients. Il apparaît alors utile de combiner ces 2 éléments pour permettre à LALLIER de centraliser sous un format commun l’ensemble des factures (tête et corps) des partenaires, d’en réaliser une consolidation puis d’en extraire toutes les statistiques utiles et nécessaires.

2.2.3 Échanges clients



Sur le plan du principe, LALLIER-Fruits dispose d’un ensemble de clients [adhérents + clients non adhérents] pour le compte de qui elle réalise des opérations d’Achats et d’Imports [parfois Export]. L’objectif attendu et décrit dans le présent cahier des charges est la mise en place d’une organisation et d’outils d’échange de données informatiques entre l’ensemble de ses adhérents et LALLIER. Actuellement chaque adhérent dispose de son propre système d’échanges de données informatisées [EDI], mais ces systèmes sont hétérogènes. De plus, les échanges réalisés sont incomplets, et ne permettent pas d’obtenir des informations de synthèses statistiques, ni de réaliser une diffusion de ces informations.

2.2.4 Échanges fournisseurs Le projet n’est pas totalement défini chez LALLIER, mais il doit permettre de caractériser les échanges actuels avec les fournisseurs et réaliser une BOURSE. Interlocuteur LALLIER-Fruits : Jean Sacroix.



3. Objectifs et contraintes

Le présent cahier des charges définit le cadre de travail, les règles de gestion, les données significatives, ainsi que les règles d’implantation du système d’échanges de données informatiques attendue par la société LALLIER-Fruits, sous forme d’un réseau physique externe et d’un ensemble d’outils informatiques. Les objectifs visés par ce projet sont : � Centralisation des données [pour accessibilité par chacun] � Diffusion des données � Normalisation des données échangées � Exploitation optimale des données [conso-stat]

La société LALLIER-Fruits visant à moyen terme une mise aux normes ISO 9002, le projet informatique s’inscrit dans ce cadre. Les produits doivent être hautement paramétrables et parfaitement interfacabl es entre eux, ainsi qu’avec l’outil ERP actuellement mis en place dans le cadre de sa réinformatisation et avec d’autres outils tels que les outils de bureautique. Les données transmises aux différents acteurs (Partenaires, clients,…) feront l’objet de niveaux de confidentialité différenciés et précisément définis. L’ensemble des outils et règles de travail devra être respectueux d’une part des prestataires informatiques des partenaires (informations à leur communiquer, échanges et dialogues), d’autre part des interfaces et format (principalement dans les éditions) qu’utilisent les partenaires. Les logiciels nécessaires aux traitement seront acquis en conformité avec les exigences réglementaires liés au nombre de licences. Les outils seront, dans la mesure du possible, basés sur des produits du marché ou à défaut développés spécifiquement pour LALLIER. Il devra être possible soit à LALLIER (pour les parties la concernant), soit aux partenaires, pour leurs parties, de paramétrer le maximum d’éléments et de pouvoir modifier ce qui ne concerne pas les éléments de descriptions de données et de base de données. Les conventions adoptées dans le présent document sont les suivantes :

� Les éléments décrivant une règle de gestion sont notés sur fond grisé et numérotés de manière unique sous la forme RGxxx pour la gestion commerciale et RCxxx pour la gestion comptable et financière

� Les éléments décrivant des points clés sont notés sur fond grisés et précédés d’une coche

� Les listes descriptives sont précédées d’une flèche et leurs sous-parties d’un point

� Les schémas sont légendés de manière unique et une table des figures est disposée en fin de document

� Le présent document est disponible en format PDF [pour le logiciel Acrobat Reader 3.00] sur simple demande



4. Acteurs et Rôles

4.14.14.14.1 Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet « Mercuriales clientMercuriales clientMercuriales clientMercuriales client »»»»

Partenaires

Groupe pilote

Réseau et matériel

France TélécomAlain BerganrdJérome Nivard

Synergie SystèmesMaître ouvrage

J.F. Detrans et Gilles Arnaud

Lallier-FruitsMaîtrise d'oeuvre

Comité de pilotage

Lalier SA

André Partes

Lallier SA

Jérome Poidevin

Lallier SA

Pierre Destard

InfinéConsultant

Patrick Naballian

OPENSYSInformatique interne

Yves KargolenEchanges

INF

OR

ME

Diff

usio

nF

orm

atio

n

Mod

èle

- M

aque

tteF

orm

atio

n

Tes

t - V

alid

atio

n

Ech

ange

s

TestsImplantation

Ech

ange

s

Figure 1 : Acteurs impliqués dans le projet

Détails des acteurs centraux :

� Synergie Systèmes : maître d’ouvrage chargé de la réalisation du projet, � M. André Partes : responsable décisionnel chargé d’étudier les problèmes

administratifs, stratégiques et financiers du projet, les implications en terme de gestion. Il fournit les réponses et prend l’ensemble des décisions finales, il valide ainsi les propositions émises par les SSII,

� Mrs. Jérome Poidevin et Pierre Destard : les responsables de suivi, chargés du suivi technique du projet sur les plans matériels, logiciels et techniques, coordonnent les divers groupes de travail. Le responsable de suivi interne assurera le contrôle et la mise en œuvre de la phase de tests et d’essais avant la recette finale,

� Groupe Pilote : les Partenaires chef de file (voir tableau ci-après), � Groupe utilisateurs : les autres Partenaires.



AME LOGAR Rennes FOIS & FILS Caen ASTELLON Toulouse SAINT FRUIT Bourg Blanc BACOLIN Cannes FRUIT LAND Saint Jean de la Ruelle LARCHET Bois Grenier PAMSA Strasbourg MORANGE Saint Paul Cap de Joux SIOPF Rungis DE MERMIN Marmande SODINSA Rungis

Figure 2 Liste des membres du Groupe Pilote

4.24.24.24.2 Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet « Mercuriales fournisseursMercuriales fournisseursMercuriales fournisseursMercuriales fournisseurs »»»»

Ces éléments ne sont pas connus à ce jour. Le projet est repoussé dans cette attente.

4.34.34.34.3 Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet «Acteurs et rôles du projet « ConsoConsoConsoConso----StatStatStatStat »»»»

Ils sont identiques à celui du projet Mercuriales.



5. Cadre de la mise en œuvre des mercuriales clients

Ci dessous sont définies les relations réciproques existantes entre les acteurs.

5.15.15.15.1 Compléments et assistancCompléments et assistancCompléments et assistancCompléments et assistanceeee

La société LALLIER-Fruits reste disponible pour fournir rapidement toute information ou document nécessaire qui ne figurerait pas dans le présent document. De même tout besoin en visite des locaux pour les calculs d’implantation réseau, les contrôles des câblages actuels, etc. seront facilités pour toute demande.

5.25.25.25.2 Organisation et planningOrganisation et planningOrganisation et planningOrganisation et planning

Les étapes à suivre au cours du projet sont les listées ci-après :

1. étude initiale 2. recueil de l’existant (réunions et mémos), 3. cahier des charges initial (non diffusé), 4. sélection des prestataires, 5. cahier des charges (le présent document), 6. réception et validation du cahier des charges, 7. maquettes, 8. développements, 9. travaux des groupes pilotes, 10. finalisation des développements, 11. tests et recette, 12. déploiement, 13. synthèse et ajustements des développements, 14. bilan et synthèse du projet.

Les contraintes d’activités du secteur des fruits et légumes d’une part et le début d’année fiscal d’autre part font que le planning initial2 est le suivant :

MAI JUIN JUILLET AOUT SEPT OCT. NOV DEC JANVIER FEVRIER

1 Etude2 Existant3 CdC Initial

4 Sélection Prest.5 CdC6 Valid. Cdc7 Maquettes8 Developpement9 Groupes Pilote10 Finalisation11 Tests12 Déploiement13 Ajustement14 Bilan

2 du fait du nombre d’intervenants extérieurs le planning sera ajusté régulièrement



5.35.35.35.3 MoyensMoyensMoyensMoyens

Les moyens se décomposent en domaines distincts : • Domaine Mercuriale

• les mercuriales traitées à travers Excel, • le traitement statistique des mercuriales au sein d’une base de données SQL

• Domaine Conso-Stat • les outils de réalisation de fichiers « Factures » exportables en respect des

règles de confidentialité depuis le partenaires (outils qui seront nommés « Masqueur »),

• les outils de consolidation factures et les outils de statistiques

� maquette des formulaires et tableaux Excel, � traitement automatisés Excel, � maquette de l’outil dit « Masqueur » � modèle des échanges (flux logiques et physiques, périodicité…), � méthode de test et de validation, � maquette des bases de données, � maquette des outils de consolidation des Factures � requêtes SQL de statistiques Mercuriales et Factures, � maquette et traitement des états, � règles et outils de diffusion (par les listes de diffusion aux Partenaires et par

les données statistiques sur Intranet), � méthodes et procédures d’échanges avec Navision3, � méthode de test et de validation.

5.45.45.45.4 ClaClaClaClauses de propriétéuses de propriétéuses de propriétéuses de propriété

La proposition et le contrat doivent englober les règles afférentes à la cession des sources des logiciels4 spécifiques d’une part en cas de cessation d’activité du prestataire, et d’autre part dans le cas de non reconduction d’un contrat de maintenance et mise à jour, durant les années futures. L’ensemble des sources devra être déposé afin de permettre à la société LALLIER-Fruits de poursuivre son exploitation et le maintien du logiciel commercial, en cas de défaillance grave ou de cessation d’activité du prestataire. Dans ce même cadre, les clauses spécifiant la maintenance permanente en état d’exploitation du système dans sa totalité [réseau, matériel, logiciel] par les prestataires concernés (France Télécom, Sysop, Commédia systèmes, BGI).

5.55.55.55.5 ContactsContactsContactsContacts

Les contacts sont : � Au sein de la société M. André Partes pour toutes les questions

administratives, financières, de planning, etc. � Au sein de la société M. Jérome Poidevin, pour toutes les questions de

savoir-faire métier, d’organisation, etc.

3 en collaboration avec Sysop 4 Ensemble des outils créés par le prestataire aussi bien en terme de logiciel indépendant qu’en terme de macro-commandes, de tableaux, etc.



� Au sein de la société M. Jean Sacroix, pour toutes les questions de savoir-faire lié aux notions de fournisseur F&L.

� Au sein de la société M. Pierre Destard, pour toutes les questions techniques et informatiques.

� A l’extérieur de la société M. Patrick Naballian, pour toutes les questions techniques, organisationnelles, de sécurité informatique, etc.

� Au sein de la société OPENSYS, installant le système ERP de LALLIER, M. Kargolen.

� Au sein de la société Synergie Systèmes, MM JF Detrans et Gilles Arnaud.



6. Aspects techniques du projet « Mercuriales Clients »

6.16.16.16.1 Implantation matérielleImplantation matérielleImplantation matérielleImplantation matérielle

RESEAU INTERNE PARTENAIRES

LS

Serveur de donnéesERP/SQL Server

Site centralEthernet/NT

RouteurMulti-voies

Global Intranet(France Télécom)

Séparation des systèmes d'Echange(EDI) et de Mercuriales

ServeursHTTPproxySMTPNNTP

Serveur d'ApplicationTCP/CITRIX

Centralisation :- Citrix Serveur- Application Excel- Base SQL- Outils de consolidation- Préparateur de Bourse

Centralisation :- Insertion des mercuriales dans ERP- Analyse interne Lallier

PartenairesMercuriales : Feuilles Excel

EDI

Internet

PartenairesMercuriales : Feuilles Excel

Extension futurepossible

Figure 3 : Schéma simplifié du réseau attendu

L’informatisation sera effectuée sur un double base réseau : • réseau externe basé sur Global Intranet (GI) et Plate-forme Internet (PI), • réseau local interne pour le siège et le bureau.

Elle sera accomplie sur une double base matérielle : • serveur Citrix sous environnement Windows NT avec logiciel Excel en fond, • PC sous environnement Windows NT avec licence Citrix chez les

Partenaires. Chaque Partenaires aura la possibilité de relier l’équipement à son réseau interne. Cette option reste plutôt à envisager dans le cadre d’une évolution, dès lors que les phases de tests et de mise en œuvre des échanges seront validées.

6.26.26.26.2 Usage de l’équipement par les PartenairesUsage de l’équipement par les PartenairesUsage de l’équipement par les PartenairesUsage de l’équipement par les Partenaires

Les utilisations du matériel acquis seront les suivantes : • accès Internet au fournisseur d’accès pour communication avec LALLIER, • accès au serveur de Programmes (sous Citrix) de LALLIER pour l’usage

d’Excel (à seul fin de gestion des mercuriales sécurisées), • échanges de mercuriales et autres données via l’e-mail (ou

téléchargement) avec LALLIER, • réception via l’e-mail de mercuriales personnalisées,



• consultation de la bourse des mercuriales fournisseur et des statistiques de mercuriales client sur l’Intranet.

L'évolution amènera une utilisation de type EDI sur Internet tant dans le cadre des Mercuriales et Conso-Stat que d’autres applications. L'équipement décrit dans ce dossier est prévu pour être utilisé dans le cadre de l'échange entre la société LALLIER et les Partenaires via Internet. Toute application étrangère à cette activité ne doit pas être installée sur ce matériel. Une ligne téléphonique séparée sera utilisée pour ces échanges. Pour tout équipement complémentaire, notamment pour une connexion future de la machine sur leur réseau interne5, les Partenaires pourront poursuivre normalement leur collaboration avec leur prestataire informatique habituel.

6.36.36.36.3 Formalisme des informationFormalisme des informationFormalisme des informationFormalisme des informations reçuess reçuess reçuess reçues

Le principe retenu est la mise en place d’une feuille de modèle Excel contenant l’ensemble des données de référence (produits avec codes, conditionnements, etc. – liste des Partenaires, chef de files, etc.). Chaque chef de file en se connectant demande :

• soit à charger le modèle (création d’une nouvelle mercuriale), • soit à modifier sa mercuriale précédente.

Il aura en outre la possibilité de demander la création d’un nouveau modèle de mercuriale.

6.3.1 Conception d’un nouveau modèle de mercuriale La création d’un nouveau modèle de mercuriale doit suivre les étapes suivantes :

1. Le chef de file émet un besoin de format de mercuriale (soit suite à la demande d’un client, soit sur sa propre initiative),

2. Synergie Systèmes élabore le modèle, 3. Le modèle est transmis au chef de file puis à LALLIER Fruits pour validation 4. Le modèle est mis à disposition dans le répertoire des modèles.

6.3.2 Maquette des tableaux de saisie

Le tableau se compose de 2 parties : • Un ensemble d’onglets de saisie, utilisable uniquement par le chef de file :

o onglet de présentation de la mercuriale avec la date du jour, la période de référence (semaine), les références du chef de file, du client et des destinataires avant validation et après validation

o onglet des fruits o onglet des légumes

• Un ensemble d’onglets de référence avec o une liste des Partenaires et Chefs de files o une liste des Clients

La partie 1 est la seule utilisable par le Partenaires ; la seconde est masquée et protégée. Le principe retenu est basé sur des formules de recherches et de tests. Ceci dans un double but :

• éviter l’implantation de trop de macros-commandes toujours plus lourdes à maintenir,

• permettre un recalcul immédiat de la mercuriale en réduisant au maximum les manipulations (pas de boutons pour passer d’une saisie à l’autre par exemple). Ceci dans le but d’avoir un outil le plus simple possible.

5 réalisé entièrement sous la responsabilité du Partenaires



Outre les calculs de base (+ - x ÷) et pour faciliter la maintenance, il a été décidé de limiter les formules de calculs à la série suivante :

• SI Pour les tests de valeurs • RECHERCHEV Pour le recherche dans les listes de référence • ARRONDI Pour les arrondis de valeurs en francs • MAX Pour la définition de la valeur maximale d’une liste • ESTNA Pour savoir si une recherche a abouti • CONCATENER Pour mettre en forme du texte issu de plusieurs zones • TEXTE Pour transformer un nombre en texte pouvant être mis en

forme

Mercuriale Feuille Fruits Feuille légumes Liste Crénistes Liste Clients

MODELE EXCEL : MERCURIALE.XLT

Onglets de saisieUtilisateur : CHEF DE FILE

Onglets de référencesUtilisateur : CRENO-IMPEX

Figure 4 : Répartition des onglets Excel de Mercuriales clients

La partie 2 est une simple série de listes de données. On trouvera ci-après la maquette initiale retenue pour les feuilles Excel. Les zones grisées y représentent les zones de saisie dans lesquelles travaille le chef de file. Toutes les autres sont soit des valeurs constates (titres, noms, etc.) soit des valeurs calculées (semaine, période, prix vente pièce, etc.). Les zones ne relevant pas de la saisie seront protégées par mot de passe, afin d’éviter tout risque d’erreur ou d’altération de la feuille. La zone message ne contiendra pas de valeurs calculées. Les données y figurant seront le cas échéant saisies par le chef de file.



Date 25/02/99SemainePériode

Client C001 Sodexho

Chef de file 1 Chef de file 1

XXXX1 AME HASLEXXXX3 ARZENTON

XXXX31 PRIMEURS 77

Chef de FileDébut de saison Fruits

LégumesFin de saison Fruits

LégumesProduits conseillés Fruits

LégumesProduits déconseillés Fruits

Légumes

Message

Mercuriale

Destinatairesavant validation

du lundi 22 février 1999 au vendredi 26 février 1999 semaine n° 8

Figure 5 : Page de Garde de saisie

La page de garde se compose de 4 types de cellules avec : 0 Du texte de fond, non modifiable (en fond blanc et texte gras) 1 Une zone de saisie (en fond gris) 2 Un calcul d’après les données saisies (en italique sur fond blanc) 3 Une zone de saisie utilisable uniquement par les partenaires applicateurs pour

des messages destinés au client

Code Désignation U.V Origine Catégorie U.C PV Facturé Poids Nb P / Cond. Poids PV Pièce Légumes crudités

Betterave cuite Kg VDL 1 Kg 5,10 F 10 Kg 10 10 Kgs 0,51 F/Kg P2 P3 P4

Salades

Batavia Colis FRA 1 Pièce 56,00 F 12 12 Pièces 4,67 F/Pièce

B2 B3

Fruits

Pomme golden 65/70 Kg VDL Pièce 5,80 F 14 Kg 8 8 Pièces 0,73 F/Pièce

PG2 PG3 PG4 PG6

Figure 6 : Exemple de page de saisie Mercuriale



Physiquement, la partie « Fruits » sera sur un onglet différent de la partie « Légumes » afin de faciliter le travail de saisie. Les pages de saisie (une page Fruits, une page Légumes) ne comportent qu’une colonne de saisie : celle du prix négocié.

6.3.3 Maquette des fichiers de consolidation Les mercuriales sont créées d’après un modèle EXCEL (Fichier XLT) puis passent pas 6 états différents sous responsabilité du chef de file :

1. saisie d’une proposition de mercuriale (prix de base par produit), 2. transmission de la proposition de mercuriale aux chefs de file des autres

régions travaillant avec le même client qui émettent un avis [phase optionnelle],

3. modification éventuelle de la mercuriale, 4. transmission au client (les prix serviront de base à la fin de négociation), 5. mise à jour et validation de la mercuriale à l’issue de la négociation avec le

client, 6. diffusion de la mercuriale validée aux destinataires (notamment aux

Partenaires en relation avec le client dans la région). La mercuriale validée (prix applicable par produit) est donc adressée aux Partenaires concernés par ce client sur la région ainsi qu’à des partenaires pour leur seule information. La diffusion est effectuée auprès d’une liste de destinataire (Partenaires, Partenaires chef de file, groupe LALLIER…). Il n’est normalement pas fait mention du fait que la mercuriale soit adressée pour information ou pour application, chaque destinataire reconnaissant la nature de la mercuriale. Mais pour des raisons de traitements informatiques, cette notion sera mémorisée avec la mercuriale. La saisie des informations relatives aux mercuriales est uniquement effectuée par le chef de file. Ce dernier est défini pour une région Client donnée ; la mercuriale qu’il réalise est transmise pour application à des partenaires de cette même région.

CA1CA1CA1CA1

CA2CA2CA2CA2

CA3CA3CA3CA3

Figure 7 : Exemple de carte de région Client pour application de Mercuriale

L’organisation6 logique des fichiers se découpe en : • répertoire du ou des modèles Excel (fichiers XLT), • répertoire des mercuriales saisies non validées (fichiers XLS),

6 sous réserve de modifications techniques



• répertoire des mercuriales validées non consolidées, • répertoire des mercuriales consolidées, • bases de données SQL en séparant la base des données consolidées

servant à l’envoi d’information via l’e-mail aux Partenaires, du traitement statistique des mercuriales consultable directement sur Intranet.

Mercuriale.xlt

Modèles

Mercuriales validées

AME990812.xls

AME990820.xls

ARZ990807.xls

etc.

SQL

Base Consolidée.SQL

Bourse SQL

Mercuriales

Mercuriales saisies

SAP990823.xls

Modèle de Mercuriale pour la saisie par lesélaborateurs chez les crénistes

Mercuriales saisiesen attente de validation par chefs de files

Mercuriales validéesen attente de consolidation, non modifiables

Mercuriales consolidées

SAP9907820.xls

AME990720.xls

ARZ990717.xls

etc.

Mercuriales validées et consolidées dans labase SQL, non modifiables

Bases de données :1 - Mercuriales consolidées2 - Statistiques pour Internet

Figure 8 : Base des répertoires des mercuriales

La base des mercuriales consolidées doit être le plus simple possible et viser à 4 objectifs :

• Mémorisation de toutes les données utiles o Partenaires : code, nom, adresse, adresse e-mail, téléphone, fax, etc. o Chef de file : code, nom, poste et emploi occupé, téléphone, fax, e-mail, etc. o Produits constitutifs des mercuriales : code, GENCOD / EAN13 / etc., libellé, famille,

conditionnement, saisonnalité, caractéristiques, etc. o Mercuriales : En-tête avec date, etc. c’est le 1° onglet de saisie (ne figurent à priori

que les données saisies) o Lignes de mercuriales : Lignes de détail avec prix, saison, conseil, etc. (toute la ligne

est présente) • Accès rapide par requête SQL (SELECT x FROM x WHERE x ) • Liens aisés avec Excel et Access via ODBC d’une part et avec Navision

d’autre part • Transfert vers les données statistiques pour alléger l’utilisation de cette

dernière (aucune requête complexe sur la base consolidée pour les données statistiques, mais simplement visualisation d’une ou plusieurs situations instantanées)



Le modèle actuellement étudié se présente ainsi :

CRENISTE

CHEF FILE

CLIENT

REGION CLT DEPARTEMENT

MERCURIALE VALIDEE

Recoit

Elabore

Concerne

Découpe

Regroupe

LIGNES MERCURIALE

Détaille

PRODUITS F&L MERCURIALES

Décrit

CONDITIONNEMENT

GENCOD / EAN

FAMILLE

EquivautRegroupe

Place

REGION CRENO

Regroupe

Figure 9 : Maquette de la base SQL des Mercuriales

6.3.4 Maquette des fichiers de résultat

Les fichiers de résultats sont ceux qui contiennent les résultats d’extractions de requête. Il est envisagé 4 structurations que les possibilités techniques devront confirmer ou infirmer par la suite lors de la réalisation :

• Une sous forme de tableaux Excel • Une sous forme de fichier Access • Une sous forme de fichier ASCII (DOS) ou ISO (Windows) avec ou sans

délimiteur (longueur fixe des champs ou longueur variable avec des caractères délimiteurs)

• Une série de pages HTML (utilisable sous Internet Explorer ou Netscape) Les 3 premiers devant servir à des échanges par « mailing-list », c’est à dire liste de diffusion par mail. La dernière permettrait une consultation au sein du site LALLIER par code d’accès protégé ou plus utilement en Intranet. Dans ce dernier cas, une arborescence de base devrait permettre d’accéder soit à des statistiques dynamiques, c’est à dire affichées en fonction d’une demande, soit à des statistiques communes et prédéfinies. Dans les deux cas, un lien vers les affichages tableaux et graphiques doit être offert, ainsi que la possibilité de télécharger les résultats dans un forme simple (texte tabulé par exemple pour les dynamiques, et Excel ou Access pour les prédéfinies). Le choix du format fichier est à définir en fonction des réponses aux questionnaires émis pour les Partenaires.



Les règles édictées pour ces fichiers doivent être les suivantes :

RG 1. Format commun à tous les Partenaires RG 2. Structure identique dans toutes les formes (Excel, Access, etc.), c’est à dire

ensemble des données identiques dans chaque format RG 3. Séparation formelle des données d’en tête ou descriptives, des données et

valeurs de statistiques RG 4. Valeurs financières en FF et en € RG 5. Lien clair entre les données numériques et la représentation chiffrée RG 6. Statistiques basées sur les critères minimum suivant :

• Zone géographique d’application • Produit • Famille de produit • Conditionnement • Saisonnalité • Tranche de prix • Tranche de poids • Période d’application ou date précise • Partenaires applicateur

Données consolidéesStatistiques dynamiques

Liens vers statiquesprédéfinies

Page d'accueil

Statistiques graphiques

Formulaire de recherched'information

Fichier de stattéléchargeable

Données consolidéesStatistiques prédéfinies

Statistiques graphiquesFichier de stattéléchargeable

Envoi du fichierpar mail

Figure 10 : Principe des pages HTML de statistiques

Dans le cadre des appels de statistiques dynamiques, les règles minimales retenues sont :

RG 1. Visualisation des infos disponibles pour chaque critère avant toute sélection : • Combo des zones géographiques • Liste sélectionnable des produits, familles, conditionnements, saisons • Périodes existantes • Combo des partenaires

RG 2. Liens aisés entre données de recherche, données résultantes, graphiques et téléchargement



6.3.5 Maquette des tableaux de résultat

On souhaite réaliser ici un ensemble de tableaux ET graphiques résultants. Ceux-ci doivent pouvoir être géré indifféremment dans un tableau, directement depuis la base SQL avec des outils tels que Jet ou autre, transmis à la base Navision ou alimentant les statistiques sur Intranet. Pour exemple (qui doit être considéré comme non limitatif mais illustratif uniquement) on propose un tableau donnant les valeurs minimales, maximales, moyenne et la tendance sur les prix de vente de l’ensemble des produits, pour une période considérée et une zone géographique donnée. Pour un produit, l’évolution des prix sur une période et une zone donnée avec minimum, maximum et moyenne (ou fermeture7), ainsi que le graphique associé.

Variété U.V Origine Catég. U.C PoidsNb Pièces / Conditionmt

Poids PV Minimal PV MaxiMoyenne sur

périodeTendance

sur période

CarottesAspergesAuberginesBlettesCeleriChouxChoux fleursConcombreEndivesNavetPoireauxPoivronsRadisSaladeTomates

AbricotsFraisesMarronNectarinesPêchesRaisins

Fruits

Caractéristiques Statistiques

Légumes

Code produit

Désignation

Figure 11 : Exemple de tableau de synthèse statistique sur une période ou une zone

Carottes XXXXXX Mini Max Moyennejanvier-99 1,25 F 1,32 F 1,27 F

février-99 1,18 F 1,29 F 1,23 F

mars-99 1,23 F 1,28 F 1,25 F

avril-99 1,19 F 1,34 F 1,26 F

mai-99 1,25 F 1,35 F 1,31 F

juin-99 1,20 F 1,25 F 1,22 F

juillet-99 1,17 F 1,33 F 1,23 F

Figure 12 : Tableau de suivi mensuel d'un produit

7 Prix en fin de période



1,00 F

1,05 F

1,10 F

1,15 F

1,20 F

1,25 F

1,30 F

1,35 F

1,40 F

janv-99 févr-99 mars-99 avr-99 mai-99 juin-99 juil-99 août-99 sept-99 oct-99 nov-99 déc-99

Val

eur

au k

ilo

Figure 13 : Graphique associé à l'évolution d'un cours

6.46.46.46.4 Traitement statistique Traitement statistique Traitement statistique Traitement statistique des mercurialesdes mercurialesdes mercurialesdes mercuriales

La compilation des mercuriales se fera :

• pour un produit donnée ou pour plusieurs produits, • sur une période ou sur plusieurs périodes.

Pour chaque cas, trois cas pourront être considérés :

• un client sur les régions d’application, • un groupe de clients (indépendamment de toute région d’application), • tous les clients.

Les données produites seront :

• code produit (EAN/GENCOD), • désignation, • prix de vente, • des données de synthèse : prix moyen, prix et écart minimums et maximums.

Afin de gérer ces informations, il est considéré comme indispensable de pouvoir disposer des informations suivantes pour chaque produit :

• Références o Période de référence (date début, date fin, échelle de temps, durée de période) o Échelle des valeurs (valeur minimale, maximale de l’échelle, pas d’échelle, unité)

• Valeurs durant la période avec spécifiquement : o La valeur d’ouverture (1° valeur de la période) o La valeur de fermeture (dernière valeur de la période) o Les valeurs minimale et maximale sur la période

• Valeurs calculées sur la période o Valeur moyenne (référence) o Droite de tendance



Ceci peut se visualiser par le schéma suivant :

7181

6983

57 52

2742 48 45

Valeur Maximale

Valeur Moyenne

Echelle de référencepar exemple en Francs

Tendance

2

Durée période

Valeur MinimaleDATE DEBUT

PERIODEDATE FINPERIODE

4

6

8

Valeur d'ouvertureInitiale de période Valeur de fermeture

Finale de la période

Il apparaît qu’actuellement toutes ces informations ne sont pas utilisées (cas de la tendance qui ne semble pas de réelle pertinence) ; dans l’optique d’une évolution future, il est décidé de permettre l’accès à toutes ces informations, afin de ne pas avoir à reconstruire les applications réalisées.

6.56.56.56.5 Modalité des échangesModalité des échangesModalité des échangesModalité des échanges

Les échanges de mercuriales s’effectuent sur la base de 4 acteurs :

• Le chef de file qui élabore la mercuriale, réalise la saisie de la mercuriale, qui vérifie et valide la mercuriale

• Le client qui est concerné par cette mercuriale • LALLIER qui recueille les mercuriales en assure la diffusion, la

consolidation et les extractions statistiques • Les Partenaires en séparant ceux ci en 3 ensembles :

o L’ensemble des Partenaires pouvant accéder à la consolidation de mercuriale, aux statistiques et à la bourse

o Les Partenaires devant appliquer une mercuriale donnée o Les Partenaires devant être informés d’une mercuriale donnée

Le circuit général de réalisation d’une mercuriale peut se schématiser ainsi :



CRENISTE

AutresChefs de FileChef de file

élaborateur

Crénistes (applicateurset pour information)

CRENO

Terminal Citrix

Fax

MailOU

4 -

Val

idat

ion

5 - Diffusion

6 -

Mém

oris

atio

n

Crénistes

7 - DiffusionAccès par Intranet de Groupe

1Saisie

3- CONTROLE

VALIDATION

B - Retour (Avis)

Client

2-Négociation

Téléphone et Fax

CONSOLIDATIONSTATISTIQUES

Avant ou aprèsphase 2 suivantbesoins

A - Transmission

Figure 14 : Circuit général des échanges de Mercuriales

6.66.66.66.6 VoluVoluVoluVolumes attendusmes attendusmes attendusmes attendus

Les volumes attendus ne sont actuellement pas connus. Mais les estimations données sont les suivantes :

• Modèle Excel de la mercuriale hors Macro-Commandes 300 à 400 K • Programmation Excel 200 K • Nombre de mercuriales par semaine 10 • Nombres de lignes produits utiles par mercuriale 50 • Nombre de Partenaires y compris LALLIER 35 • Nombre de diffusion mercuriales par semaine 1750 • Volume diffusé par semaine (mercuriales seules) 130 Mo

6.76.76.76.7 Principe d’utilisationPrincipe d’utilisationPrincipe d’utilisationPrincipe d’utilisation

La base consolidée doit être utilisable soit par des extractions SQL directes, soit par des outils (tels que Navision ou ceux associées), soit par des appels en via ODBC.



Ces extractions doivent permettre de créer indifféremment des états écrans ou papiers ainsi que des exports vers d’autres structures (Excel, Access, Navision, etc.). Afin de faciliter l’utilisation, un ensemble de requêtes devra être préétabli, présentant les demandes les plus fréquemment utilisées. A charge, ensuite pour l’utilisateur de créer ou faire créer les requêtes supplémentaires. Les requêtes de base doivent permettre de :

• Recherche un produit en fonction d’un code, d’une partie de libellé, d’une famille, d’un conditionnement, etc.

• Recherche d’une mercuriale en fonction d’une date, d’une période, d’un chef de file, d’un Partenaires pour application, d’un client, etc.

• Recherche d’un prix donné et, à partir de là, obtention de la ligne de mercuriale et de la mercuriale associée,

• Recherche pour un produit, une zone et une date (ou période donnée) des valeurs statistiques,

• Recherche pour un produit et une date (ou période) des valeurs par zone géographique (départements ou autres).

6.86.86.86.8 Objectifs attendusObjectifs attendusObjectifs attendusObjectifs attendus

Les objectifs attendus du projet se définissent ainsi : • Recueil formalisé des mercuriales suivant un format commun à tous les

Partenaires. • Formalisme du PROCESS de gestion des mercuriales. • Consolidation automatique des mercuriales. • Diffusion automatique de l’information initiale (mercuriale). • Diffusion automatique de données statistiques. • Évolution commune des mercuriales, outils et process pour tous les

Partenaires. • Maintenance centralisée des outils. • Mise à disposition d’informations en interne pour les commerciaux de

LALLIER. • Constitution d’une banque de connaissances des prix et tendances du

marché des Fruits & Légumes.

6.96.96.96.9 Mode opératoireMode opératoireMode opératoireMode opératoire technique technique technique technique

Techniquement le PROCESS de gestion des mercuriales se découpe en 2 temps : • Le premier correspond aux étapes 1 à 2 de la « Figure 14 : Circuit général

des échanges de Mercuriales », (les échanges A-B ysont inclus) • Le second correspond à l’ensemble des étapes suivantes



SAISIE PAGE INITIALE1- Client2- Chef de File3- Liste des Crénistes concernés4- Message d'information générale4- Passage à feuille fruits

SAISIE PAGE FRUITS1- Prix de Vente Facturé en Francs2-Passage à feuille légumes

SAISIE PAGE LEGUMES1- Prix de Vente Facturé en Francs2-Validation initiale

- Edition automatique (si possible ?)- Transmission à Chefs de files (si possible autom...)- Transmission à Clients (si possible automatique)- Sauvegarde automatique sous forme de Mercuriale élaborée non validée

Figure 15 : Mode opératoire étape 1 Saisie

SAISIE DES CORRECTIONS1- Page initiale2- Page fruits3- Page légumes4- Validation Finale

Création automatique de la Mercuriale1- pour application avec la mailing-list associée2- pour information avec la mailing-list associée3- sauvegarde verouillée4- Lancement diffusion

DIFFUSION1- mailing application2- mailing informationINTEGRATION dans la base de données SQLLancement consolidation

CONSOLIDATION AUTOMATIQUESTATISTIQUES AUTOMATIQUESIntégration dans les données statistiquesDiffusion automatique par mailing list

Figure 16 : Mode opératoire étape 2 Validation et diffusion

6.106.106.106.10 Descriptif des outils retenusDescriptif des outils retenusDescriptif des outils retenusDescriptif des outils retenus

6.10.1 SGBD Le SGBD retenu est SQL Server de Microsoft, version 6.0 ou 7.0. Ce choix n’est pas formel et peut être modifié si les nécessités techniques ou organisationnelles le justifient.

6.10.2 Outil de développement Les outils retenus sont :

• Excel 2000 pour la conception des mercuriales • VBA et VB 6.0 pour la conception des macros-commandes et modules de

consolidation • SQL pour la conception des requêtes de base • Jet pour la conception des documents édités • Front Page et J++ 6.0 pour la conception des pages HTML

6.10.3 Plate-forme de développement Est retenu Windows NT (32 bits).

6.10.4 Plate-forme d’exploitation Est retenu Windows NT et Citrix Server qui est l’actuelle plate-forme chez LALLIER, et Windows NT avec Citrix chez les Partenaires.

6.10.5 Liens avec l’ERP Les données relatives aux clients et aux produits seront transmises par l’ERP sous formes de fichiers ASCII ou directement dans une base SQL Server. Pour la gestion des mercuriales clients, les fichiers issus de l’ERP sont :

• Partenaires • Clients • Régions ......................................... si définies dans l’ERP



• Chefs de file .................................. si définies dans l’ERP • Produits • Familles de produits • Codification GENCOD / EAN • Conditionnement

Dans la fiche partenaires et clients, trois types principaux de données seront récupérés : • données administratives (nom, adresse…), • découpage géographique et chef de file correspondant, • mode de traitement commercial (prix net, ristourne déduite…).

6.116.116.116.11 Descriptif des logiciels MercurialesDescriptif des logiciels MercurialesDescriptif des logiciels MercurialesDescriptif des logiciels Mercuriales

Sont à présenter par le prestataire: • La maquette des mercuriales sous Excel (ou autre produit si besoin) • Les macros en VB associées à cette maquette

o L’enregistrement en attente de validation d’un fichier basé sur le modèle ouvert o L’enregistrement validé du fichier issu du précédent o La génération des Mailing-List o La diffusion o L’intégration dans la base SQL

• Les liens avec Navision : le format des fichiers nécessaires à la transmission de données de l’ERP vers la base SQL

• Les requêtes minimales SQL • La programmation sous SQL

6.126.126.126.12 SécuritéSécuritéSécuritéSécurité

La sécurité au sein du logiciel et du système doit au minimum fournir ces points : RG 1. Droit d’accès par niveau, séparation de l’administrateur [OS / NOS / SGBD /

LOGICIEL] RG 2. Intégration aisée à l’outil de sauvegarde de LALLIER avec automatisation des

opérations d’exploitation de type « sauvegarde » et « reprise sur incident ». RG 3. Interdiction de créer / modifier / supprimer des données, formules et requêtes en

dehors du cadre de l’administrateur LALLIER. RG 4. Possibilité en cas d’incident de restauration des données soit sur le site central. RG 5. Maintenance téléphonique assurée dans la semaine suivant horaires du prestataire. RG 6. Enchaînement automatiquement d’une opération et de l’édition en découlant. RG 7. Génération automatique des éditions associées à une opération. RG 8. Obtention les statistiques d’utilisation du système pour savoir les volumes

d’opérations traitées et les flux d’informations générées afin d’aider l’administrateur du système dans le suivi des opérations durant la montée en puissance du système.

RG 9. Gestion pluriannelles des statistiques. RG 10. Traitement des archives. 6.12.1 Accès au réseau

L’accès réseau est défini par l’accès via Citrix et le GI de France Télécom pour les partenaires. Les accès à la base de données des mercuriales se font soit par diffusion, soit en interne à LALLIER par l’appel des requêtes SQL.

6.12.2 Sauvegarde et restauration des données L’ensemble des répertoires de mercuriales doit être inclus dans la définition des sauvegardes interne à LALLIER

6.12.3 Archivages des mercuriales



Il est prévu sur plusieurs années et doit suivre les procédures internes de LALLIER.

6.136.136.136.13 AspectsAspectsAspectsAspects techniques du projet Mercuriales fournisseurs techniques du projet Mercuriales fournisseurs techniques du projet Mercuriales fournisseurs techniques du projet Mercuriales fournisseurs

Le projet est suspendu en attente de plus d’informations.

6.146.146.146.14 ValidationValidationValidationValidation

Les règles minimales définies sont : 0 La première étape de validation correspond aux présentations des maquettes,

celles-ci seront corrigées en fonction des remarques de LALLIER, 1 La seconde étape de validation correspond à la présentation des produits

(premier niveau de réalisation, version bêta) au groupe pilote, ceux-ci seront corrigés en fonction des remarques du groupe pilote et de LALLIER,

2 La troisième étape est celle de diffusion auprès de l’ensemble des partenaires, les produits seront alors suivis par le prestataire durant la période de garantie,

3 La validation sera associée à la correspondance entre la réalisation remise à LALLIER et diffusée aux partenaires et le présent cahier des charges, complété des remarques du groupe pilote dans la mesure où celles-ci ne remettent pas en question le présent cahier des charges mais le complètent ou l’améliorent.

6.156.156.156.15 RecettesRecettesRecettesRecettes

6.15.1 Recette matérielle Elle fait l’objet d’une recette particulière et contradictoire entre le client, Synergie Systèmes et le fournisseur du matériel retenu à savoir BGI. Cette recette sera effectuée à la réception du dernier élément matériel fourni par BGI dans le cadre de la commande associé au projet du présent contrat. Elle sera réalisée sous forme : • d’une réception contradictoire de réception du dit matériel, • d’une réception contradictoire de bon fonctionnement du dit matériel et de ses outils

associés (OS, NOS, outils d’administration, outils d’exploitation, outils et matériels de sécurité, etc.),

• d’une réception contradictoire des performances du dit matériel, ceci afin de vérifier d’une part la conformité par rapport aux besoins exprimés dans le cahier des charges et lors de réunion de travail entre les cocontractants, et d’autre part, l’adéquation du matériel (serveur, réseau, etc.) par rapport aux besoins associés à l’emploi des logiciels spécifiés dans le présent cahier des charges.

6.15.2 Recette provisoire La recette sera effectuée en deux temps : • démonstration, par SYSOP, des fonctionnalités du produit livré, et de l’adéquation

avec le cahier des charges et/ou les préconisations et demandes issus des réunions des groupes de travail

• après prise en main et durant une période d’une quinzaine de jours dont la durée exacte sera définie pour chaque module remis, analyse par le client du produit sur la base du jeu d’essai.

La réalisation des tests devront faire apparaître par le client : • les éléments validés pour lesquels fonctionnalités et résultats sont conformes • les éléments à rectifier pour lesquels des disfonctions apparaissent et nécessitant

des correctifs • les éléments refusés pour non conformités



Ces éléments devront être remis par écrit à Synergie Systèmes dans les plus courts délais, afin que Synergie Systèmes puisse procéder sans gêne ni retard aux correctifs nécessaires. Lorsque l’ensemble des éléments est validé, la recette est effectuée sous forme d’un document écrit signé par les deux cocontractants. Lors de la remise de l’application ou du module, Synergie Systèmes fournira toutes les indications et assistera le client pour qu’il puisse procéder correctement et rapidement aux tests.

6.15.3 Recette finale Cette recette s’effectuera à la remise des derniers éléments et du début d’exploitation par le client, soit le xx septembre xxxx. Elle correspond au début de la période de garantie de six mois définie dans le présent contrat avec Synergie Systèmes. Durant cette période, le client devra tenir à jour un cahier d’exploitation portant l’ensemble des pannes et incidents, avec leurs dates, heures, constat, délai d’intervention de Synergie Systèmes, et délai d’indisponibilité du produit, etc. Tout incident, panne ou dysfonctions sera communiquée aussitôt à Synergie Systèmes qui les prendra en compte dans les délais les plus courts pour y apporter corrections. Avant la fin de la période de garantie, le client avisera par courrier Synergie Systèmes de toute erreur ou malfaçon qui pourrait encore exister afin qu’il y soit procédé correction au titre de la garantie. La réception sera elle-même effectuée à date du xx septembre sous forme contradictoire comme une livraison réelle ; elle portera d’une part sur l’ensemble des logiciels, progiciels, modules, devant être livrés par Synergie Systèmes mais aussi sur l’ensemble de la documentation (papier ou électronique). Il sera procédé à un contrôle contradictoire par rapport à un bordereau de livraison et aux produits disponibles sur le système informatique. Le jeu de test et les outils de contrôle sont ceux décrits dans l’annexe et remis avec le présent document sous les références : « TEST_CTRL_CONSO »

6.15.4 Règles de recettes Le principe retenu pour la gestion des recettes sera le suivant :

RG 11. Le logiciel sera livré en 3 étapes : Gestion des saisies – Gestion des diffusions – Consolidation.

RG 12. Chaque étape fera l’objet d’une VABF de quinze jours suivie d’une recette partielle de deux semaines chacune.

RG 13. La livraison finale sera associée à une mise en place complète du logiciel avec VSR globale de 2 mois.

RG 14. Chaque VABF devra permettre des tests immédiats. RG 15. En cas d’incidents durant la VABF, chaque incident sera corrigé dans un délai de 2

jours maximum par Synergie Systèmes et la VABF reprendra pour une durée de quinze jours.

RG 16. Dans le cas où la VABF n’est pas possible, la réception du logiciel n’est pas faite et Synergie Systèmes disposera d’un délai de quinze jours à un mois maximum pour rendre le module d’étape opérationnel.



RG 17. Dans le cas où la VABF est correctement réalisée, le document de validation d’aptitude sera signé par les deux parties et la VSR partielle débutera.

RG 18. Chaque VSR fera l’objet de tests portant sur : les résultats attendus, les volumes traités et les temps de travail (délai de réponse, délai de transmission, etc.)

RG 19. Les tests sont composés d’un ensemble de données prédéfinis et d’outils de contrôle. L’ensemble des jeux de tests et des outils de contrôle sont remis avec le présent cahier des charges. Les données sont issues des données réelles manipulées par Lallier sur ces deux dernières années et basées sur un échantillon de 120 mercuriales représentatives des divers cas existants. Le jeu de tests et les outils de contrôle ont été conçus et validés par Lallier, son service qualité et son conseil informatique.

RG 20. Chaque VSR sera suivie de la remise d’un rapport de test auprès de Synergie Systèmes qui devra soit effectuer les correctifs dans un délai d’un mois maximum, sauf cas particulier dû à des difficultés techniques indépendantes des deux parties.

RG 21. Dans le cas où les jeux de tests et outils de contrôle associés devaient être modifiés, Synergie Systèmes en serait informée et recevrait un exemplaire de ces données et outils.

RG 22. Les valeurs de contrôle sont définies dans l’annexe correspondante et devront être totalement respectées pour permettre la validation de la VSRG.

RG 23. La VSRG est définie pour une période de trois mois complets à compter de la livraison finale et de la VBAF finale associée.

RG 24. Dans le cas où des incidents bloquants sont détectés durant la VSRG, celle-ci sera stoppée et repartira à zéro dès la correction des dits incidents.

RG 25. Dans le cas où des incidents non bloquants sont détectés durant la VSRG, celle-ci sera stoppée et reprendra après correction des dits incidents.

RG 26. La durée totale de la VSRG ne pourra excéder neuf mois. RG 27. Dans le cas où à l’issue des neufs mois, la VSRG n’est pas atteinte. La société

Synergie Systèmes devra reprendre son projet et le mener à son terme dans les trois mois suivants, en subissant les clauses financières de pénalité définies dans le contrat commercial.

RG 28. Dans le cas où à l’issue de ces trois nouveaux mois, le VSRG n’est pas possible, les clauses pénales du contrat seront appliquées.

RG 29. Dans le cas où à l’issue des périodes de VABF, VSR et VSRG, la société Lallier ne signale aucun incident, la validation sera automatiquement acquise.

RG 30. La société Lallier ne pourra invoquer des problèmes de personnel, de locaux ou de carence de moyens internes pour allonger ou retarder les périodes de VABF ou VSR.

RG 31. Dans le cas où des impossibilités techniques et matériels, indépendantes des deux parties (grève de transport, non fourniture électrique, etc.) venaient à retarder les vérifications et tests, les deux parties prévoient des solutions de secours pour les dits tests (locaux extérieurs, matériels de secours, etc.). Ces solutions sont décrites dans les annexes.

RG 32. La fin de la VABF globale marquera le début de la VSRG et de la période de garantie. La garantie est acquise pour un an ; en cas de suspension de la VSRG, la période de garantie sera prorogée d’autant.

RG 33. La fin de la période de garantie marquera le début de la période de maintenance ; celle-ci est définie dans le contrat de maintenance. Ce contrat ne pourra être modifié avant la fin de la première année de maintenance.



7. Aspects techniques du projet « CONSO-STAT »

7.17.17.17.1 Objectifs visésObjectifs visésObjectifs visésObjectifs visés

A partir de l’ensemble des factures émises tant par les partenaires que par LALLIER même, il doit être construit une base de données complète intégrant la totalité de ces factures (en-tête ET corps de factures). A partir de cette base consolidée, il sera alors possible de réaliser des statistiques de groupe. A partir de cette base il doit alors être possible de réaliser des statistiques en croisant des données telles que :

� Les produits (code, prix, quantités) � Les régions � Les périodes

7.27.27.27.2 Modalités techniquesModalités techniquesModalités techniquesModalités techniques

Pour aboutir à cet objectif, il importe donc de recevoir les factures des partenaires sous forme de fichiers normalisés. Chaque partenaires utilisant des échanges de type EDI, la norme retenue est celle des messages EDI classiques actuellement utilisée. On demande donc à chaque partenaires de fournir, pour une période donnée (mensuelle vraisemblablement), l’ensemble des factures qu’il a émises auprès de ses clients. Chaque partenaires devra donc sur la base de son système actuel fournir un fichier EDI complet, mais les factures réalisées peuvent contenir des informations confidentielles. Il est donc nécessaire de pouvoir, sur un fichier EDI, masquer ces informations. Deux solutions existent :

� Demander à chaque partenaires qu’il fasse élaborer par son prestataire un fichier avec masquage des zones confidentielles

� Créer un logiciel de masquage au sein de LALLIER-Fruits La 1° solution augmentant considérablement les coût s et nécessitant d’importants moyens de coordination des projets n’est pas concevable. Un outil de masquage est donc à réaliser en s’appuyant sur les règles suivantes :

RG 3. Chaque message « facture » étant basé sur des items, ce sont les segments d’un message qui seront masqués

RG 4. Une facture étant composée de 2 parties : En-tête et un corps (lignes) de facture, il doit être possible de masquer de manière distincte chacune de ces parties.

RG 5. Les règles de masquage doivent être à 3 niveaux : a) Complet : aucun segment n’est masqué b) Réduit : seuls les items constituant les conditions commerciales avec le client sont masquées c) Masqué : toutes les références du client et de ses conditions commerciales sont masquées

RG 6. Seul LALLIER doit pouvoir modifier les règles de masquage ; elles ne doivent pas être accessibles au partenaires

RG 7. Il doit exister des zones non masquables qui constituent les éléments essentiels de la notion de consolidation-statistiques. A ce jour, sont recensés : a) le n° de département du client et la date fact ure en en-tête



b) le Code GENCOD du produit, l’origine, la marque, la quantité et son unité, le conditionnement, le prix de vente et son unité (F, € ou autre) dans les lignes de facture

RG 8. A partir de ces règles, chaque partenaires doit pouvoir, à son gré définir quel niveau de confidentialité (complet, réduit, masqué) il souhaite appliquer pour chacun de ses clients

RG 9. Cette mise à niveau de confidentialité doit pouvoir s’effectuer par un outil simple et convivial fonctionnant sous environnement Windows (NT, 98, 95 ou 3.11 indifféremment)

RG 10. Les références clients permettant d’effectuer le paramétrage de la confidentialité doivent pouvoir être récupérées par un fichier d’import issu du système informatique du partenaires. Ceci afin d’éviter une saisie des références clients.

RG 11. Dans le but de confidentialité, ce fichier d’import ne doit contenir que : a) le code du client figurant sur la facture (code SIREN/SIRET ou code interne) b) le nom et l’adresse du client (pour faciliter le repérage du client lors de son paramétrage de niveau de confidentialité)

RG 12. L’ensemble du logiciel ne doit pas amener à des modifications dans le système informatique du partenaires, hormis par le double besoin de : a) pouvoir récupérer les données réduites du fichier client b) pouvoir émettre un fichier EDI de toutes les factures clients sans aucune exception pour une période donnée

7.37.37.37.3 Processus techniqueProcessus techniqueProcessus techniqueProcessus technique

7.3.1 Phase 1 : Définition des règles de paramétrag e LALLIER-Fruits doit pouvoir définir un fichier de paramétrage (non modifiable par les partenaires), indiquant le niveau de masquage de chaque segment significatif d’un message EDI de facture. Le principe retenu se décrit ainsi : Pour chaque partie (en-tête et ligne), on affiche les segments significatifs (n° et intitulé). Pour chacun de ses segments, on indique alors si, dans les niveaux « Réduit » et « Masqué », il y a masquage du dit segment. On définit les règles suivantes :

RG 13. Un segment est manipulé par : a) une référence de segment dans le message b) un intitulé c) une position, une longueur et un type au sein du message

RG 14. Un segment est soit : a) indispensable (il ne peut être masqué et se retrouve dans les 3 niveaux) b) masquable (auquel cas il peut être masqué en mode réduit / masqué)

RG 15. Tout segment caché en mode réduit l’est obligatoirement en mode masqué RG 16. Ce fichier de paramétrage est nommé « Fichier des niveaux de masque » RG 17. Toute modification de ce fichier doit être associée à une version de mise à jour et doit

faire l’objet d’une diffusion simultanée à tous les partenaires



LIGNEDETAIL DEFACTURE

EN TETE DEFACTURE

Raison Sociale

Code PostalAdresse

ContactCode NAFSIREN SIRET

Modalité de paiement

Code Article

MarqueDésignation exacte

GENCODPrix de ventePrix achatRemise

RemiseDélai paiement

Origine

Nor

mal

Réd

uit

Mas

qué

Quantité

Nor

mal

Réd

uit

Mas

qué

Donnée non masquable Donnée visible et utilisable Donnée masquée

Code communeDépartement

Réf. Intracom TVA

UnitéConditionnement

Données minimales nécessaires à toute consolidation etstatistiques du Groupe CRENO

Date FactureN° Facture

Ville

Seg

men

t

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

Seg

men

t

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

XXX

Figure 17 : Principe du fichier des niveaux de masquage

7.3.2 Phase 2 : Définition des masquages partenaire s Chaque partenaires reçoit pour pouvoir travailler :

� d’une part le logiciel masqueur, � d’autre part le fichier des niveaux de masquages

A partir de là, il va devoir réaliser une exportation de la liste de tous ses clients dans un fichier de type ASCII décrit ainsi :

N° SIGNIFIANT TAILLE / TYPE VALEUR A Un en-tête (1 par fichier) 44 C8

1 Flag de début de fichier 4 N 0000 2 Nom du partenaires 40 C

B Un corps (1 par client) 164 C 3 Code client 15 C Code SIREN 4 Nom du client 40 C 5 Adresse du client 50 C Adresse principale 6 Code Postal 15 C 7 Ville 40 C 8 Pays 4 C Code ou 1° lettres pays

C Un pied (1 par fichier) 4 C 9 Flag de fin de fichier 4 N 9999

8 C= Caractère / N=Numérique



Flagdébut

Nom du créniste

Code client Nom du client

Adresse client

Code Postal Ville

Pays

Flag fin

9 9 9 9 9

9 9 9 9 9

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A

A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A



A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A A A A

A A

AA A

AA A

AA A

1 foispour

chaqueclient

ducréniste

1 parfichier

1 parfichier

Figure 18 : Trame du fichier d’importation clients du Partenaires

A partir de ce fichier importé, chaque partenaires disposera DANS SES LOCAUX (et uniquement là) de l’ensemble de ses clients qu’il pourra paramétrer suivant un principe tel que présenté dans la maquette fenêtre ci-dessous et dans le process suivant :

1

Paramétrage Masques Clients

C0001

C0002

C0003

NiveauAdresseNomCode

Normal

Masqué

Réduit

Réduit

Réduit

Normal

Normal

AME HASLECréniste

895 Clients

Figure 19 : Exemple de fenêtre de paramétrage des droits clients chez un partenaires



DOMAINEDU LOGICIEL

MASQUEURCHEZ LE CRENISTE

DOMAINE DUPRESTATAIREOU DU SERVICEINFORMATIQUEDU CRENISTE

MasquesCRENO

Fiche client

Code client C0001

Nom

Ville

Adresse

CP

XXXXXX

XXXXXXXXXXXXXX

XXXXX

XXXXXXXXXXXXXX

En tête facture

Ligne de détail Mode Normal

Mode Masqué

Zones issues

des fichiers

du Créniste

Paramétragepar le

Créniste

Système InformatiqueCréniste

Fichier ClientExporté (ASCII)

Edition decontrôle

du paramétrage

Système Info avecLogiciel Masqueur

Impo

rtat

ion

Edition

Par

amét

rage

Figure 20 : Création du fichier de masquage des factures chez le partenaires

7.3.3 Phase 3 : Masquage d’un fichier EDI

Une fois ces éléments définis, le partenaires dispose d’un outil prêt à fonctionner. Il doit alors, à périodicité définie (mensuelle à priori) réaliser un fichier EDI de toutes ses factures Fruits et Légumes émises à ses clients. Par l’intermédiaire du logiciel Masqueur, il va lancer le process de masquage. Le logiciel doit alors procéder à une vérification du fichier avant tout masquage. Les vérifications doivent porter sur :

• La présence d’un fichier complet • La présence de messages complets au sein du fichier • La présence de tous les clients des messages dans le fichier de définition des

niveaux de masquages • La présence de messages se rapportant uniquement à la période concernée

En cas d’anomalie constatée, le logiciel édite une liste d’erreurs et ne réalise aucune opération sur le fichier.



En cas de succès, le fichier est parcouru, et pour chaque message trouvé, le logiciel doit rechercher le client correspondant dans le paramétrage des niveaux et appliquer les niveaux de confidentialités requis sur le message. Le message alors transformé est réécrit dans un nouveau fichier nommé fichier « EDI masqué » afin de ne pas altérer l’original.

DOMAINE DUPRESTATAIREOU DU SERVICEINFORMATIQUEDU CRENISTE

Système InformatiqueCréniste

Factures

Création FichierEDI Complet

Système Info avecLogiciel Masqueur

Paramétrage des Clients

C001

C002

C003

C004

FichierEDI

Edition decontrôle

Edition decontrôle

Description des masquesCRENO

Normal

Réduit

Masque

Validation

Correctiondes

masqueserronés

Erreur

TransmissionModem

CRENOFichier

EDIMasqué

Figure 21 : Processus de création du fichier EDI masqué

Une fois l’opération effectuée, le partenaires doit pouvoir réaliser 2 choses :

1. éditer, par le logiciel masqueur, le fichier EDI masqué afin de le contrôler 2. reprendre le fichier EDI masqué pour le vérifier via son propre système

informatique. Ceci implique que le fichier masqué soit effectivement totalement identique au fichier original en terme de taille, format et codification, et que les seules différences soient des différences de valeurs.

Afin d’éviter tout risque d’utilisation du fichier EDI masqué comme d’un fichier EDI classique au sein du système, on modifiera la valeurs des indicateurs de début de message afin qu’ils ne puissent être acceptés par les logiciels d’intégration.

7.3.4 Phase 4 : Transmission des fichiers EDI masqu ées Lorsque le fichier EDI masqué est réalisé et que le partenaires l’estime conforme à ses attentes, il peut alors via le mail EDI l’envoyer à LALLIER, qui le réceptionne de manière classique. Il peut aussi réaliser un envoi via le mail sur le Global Intranet du Groupe.



7.3.5 Phase 5 : Consolidation des factures Lorsque LALLIER dispose de fichiers EDI masqué, il est possible de réaliser la consolidation. Pour ce faire, un logiciel de consolidation devra être mis en place chez LALLIER, qui devra pouvoir réaliser les opérations suivantes :

1. Analyser chacun des fichiers EDI masqués qu’on lui fournit, en vérifiant qu’ils soient conformes au format de fichier généré par le masqueur

2. Éditer toutes les erreurs trouvées 3. Intégrer le fichier dans la base de consolidation

Base SQLConsoStat

FichierEDI

Masqué

Contrôleur

Fichiers intégrables

Messageserronés

Intégrateur Refusé

FichierEDI

Masqué

FichierEDI

Masqué

FichierEDI

Masqué

Figure 22 : Processus de consolidation des factures partenaires

La base de consolidation souhaitée sera la plus proche possible de la base des mercuriales et devra adopter une structure telle que celle-ci :



CRENISTE

CLIENT

DEPARTEMENT

EN TETE FACTURES

Emet

Concerne

Est sur

LIGNES FACTURES

Détaille

PRODUITS VENDUS PAR FACTURE

Décrit

CONDITIONNEMENT

GENCOD / EAN

FAMILLE

EquivautRegroupe

Place

Est faite sur

Figure 23 : Structure de la base de données Conso-Stat

7.3.6 Phase 6 : Statistiques Les statistiques devront être des résultats de requêtes SQL. Par défaut, lors de la réalisation des premières consolidation, un ensemble de statistiques élémentaires seront à créer. Puis LALLIER alimentera le produit en créant au fur et à mesure de ses besoins les statistiques qui lui sont nécessaires. L’ensemble des requêtes doit pouvoir être réalisé soit pour des éditions en direct ou par des outils comme JET avec DAO, soit par des exportations vers des outils tels qu’Excel, Access ou équivalent.

7.47.47.47.4 Règles de tRègles de tRègles de tRègles de travailravailravailravail

L’ensemble des logiciels réalisés doit respecter les règles suivantes :

RG 18. Transparence vis à vis des partenaires (les partenaires doivent exactement savoir ce qui est transmis à LALLIER dans le fichier masqué).

RG 19. Transparence vis à vis des prestataires ou des services informatiques des partenaires qui doivent savoir exactement ce qu’il est attendu en terme de fichiers et de contenus de fichiers.

RG 20. Normalisation des échanges, le système via EDI et en utilisant GENCOD est retenu. RG 21. Simplicité d’emploi, le masquage et son paramétrage doivent être le plus intuitif

possible et ne nécessiter aucune formation particulière. RG 22. Simplicité et automatisme d’installation suivant le même principe RG 23. Non interférence avec le système du partenaires. Le logiciel installé ne doit pas

modifier la base de registre du système Windows utilisé par le client, afin de ne pas créer de conflit et permettre une désinstallation aisée.

7.57.57.57.5 Conception du logiciel «Conception du logiciel «Conception du logiciel «Conception du logiciel « MasqueurMasqueurMasqueurMasqueur »»»»



Le prestataire est libre d’utiliser l’outil qu’il souhaite pour la conception du logiciel masqueur et de l’intégrateur. Les sources devront être déposés afin, qu’en cas de défaillance du prestataire, LALLIER puisse reprendre ces dernières et poursuivre l’exploitation et la maintenance du dit logiciel. Le système de statistiques doit être indépendant du logiciel masqueur afin de permettre à LALLIER de créer à son gré les statistiques qui lui sont nécessaires.

7.67.67.67.6 Exemple de résultat attenduExemple de résultat attenduExemple de résultat attenduExemple de résultat attendu

Pour exemple, on trouvera, ci-dessous, 2 extraits de fichiers EDI. Le premier est un fichier classique sans masquage, le second est un fichier sur lequel des masquages d’en-tête ont été réalisés.

7.6.1 Message EDI Complet

Début de l’extrait Complet ···BGM4380FACTURE····························53044· ·····························981216000000········································· ·········SFR······································································ ·································INVOIC002901UNEAN005····························· ··············1··································································· ··········RFF4AAK47047863·································981216·······NAD4II·3972 ·················································································· ·················································································· ···························LALLIER·FRUITS························RESP.:·M.CHAPLAIS ·····················································Z.I.·DES·ISCLES·············· ······===============····················===============····················CHATEA URENARD·······························13260·········RFFEXA·RCS·:·B302306592······· ···············RFFEXA·CAPITAL·:·1485000·F···················RFFEGN·SIRET·:·3023065 9200148················RFFEGN·APE·:·513A····························RFFEVA·FR·1351 23231568·······················NADEIV·009········································· ·················································································· ·····································································SFR·········· ·················································································· ··········BP112··································································· ·································SAINT·QUENTIN·YVELINES·CEDEX················78883 ·········NADKBY·1132·············009·············································· ·················································································· ···············································CREDIT·AGRICOLE···················· ······································································219,·ave·Fra nçois·Verdier····································································· ···········ALBI········································81000·········PAT403······· ············990125013····························································· ·················································································· ·················································································· ·····················PAT422····························05·03D··000+0000000000···+0 00000000000000+000000000000000+0000000000PAS·DE·CONDITION·D'ESCOMPTE·············· ·················································································· ·······················································PAT420····················· ··················+0000001500M··+000000000000000+000000000000000+0000000000PENALIT E·DE·RETARD·DE·PAIEMENT·:···1,5·%·*·TAUX·D'INTERET·LEGAL·························· ·················································································· ·······TDT4······································································· ··························0001················PAR·NOS·SOINS······················· ················TOD4····DDP22····················································· ·················································································· ·················································································· ·················································································· ·················································································· ·····································································LIN4000001··· ·····································MACHE·BARQ.··FRA···················SA········ ···············+000000000061390NT+000000001000KGM+000000000750+000000000046040···· ···············································IMD4F··············MACHE·BARQ.··FRA ·······························



··················································· ·················································································· TRIEVAT···································S··+0000005500·························· ·············TMA4+000000000048660································+000000000046120· ··················································ALCEA··04······················· ···············TD·········································+000000000000000+0000021 000·························FTXWPMT1·······TAUX·DE·REFERENCEMENT·DE····21.00%····· ·················································································· ·················································································· ·················································································· ····································································ALCEC··02····· ·································TX·········································+00000 0000000080+0000000180······················ ···FTXWINV3·······CTIFL···························· ·················································································· ·················································································· ·················································································· ··········································································TXS4VAT· ··································S··+0000005500+000000000046120+000000000002540

Fin de l’extrait Complet Nota : les symboles · représentent les espaces [Code ASCII et OEM 32]

7.6.2 Message EDI Masqué Dans cette exemple, les données clients-fournisseur ont été masquées pour ne conserver que les zones obligatoires de DEPARTEMENT et de DATE FACTURE, les lignes de factures n’ont pas été masquées. Les zones masquées sont remplacées par des étoiles sur fond gris, les zones utiles sont en gras sur fond noir.

Début de l’extrait « Masqué » ···BGM4380FACTURE····*****************************· ····························· 981216 000000············································· ·····SFR······································································ ·································INVOIC002901UNEAN005····························· ··············1··································································· ··········RFF4AAK47047863································· 981216 ·······NAD4II·3972·················································································· ·················································································· ···························***********************************RESP.:************** ********************************************************************************** ***=****************************************************************************** *********************************** 13************RFFE*A·RCS·:*************************** ******RFFE.A.CAPITAL.:*****************************RFFEGN*SIRET*:*********** ********************RFFEGN.APE.:*********************************RFFEVA*********** ****************************NADEIV************************************************ ********************************************************************************** ********************************************************************************** ********************************************************************************** ********************************************************************************** ************************************************************************** 78************NADKBY*1132***************************************************************** ********************************************************************************** ********************************************************************************** ********************************************************************************** ********************************************************************************** *****************************************************************PAT403*********** ********990125013***************************************************************** ********************************************************************************** ********************************************************************************** *****************PAT422****************************05*03D**000+0000000000***+00000 0000000000+000000000000000+0000000000********************************************* ********************************************************************************** *******************************



********************PAT420************************* **************+0000001500M**+000000000000000+000000000000000+0000000000PENALITE*DE *RETARD*DE*PAIEMENT*:***********TAUX·D'INTERET·LEGAL****************************** ********************************************************************************** ***TDT4*************************************************************************** **********************0001****************PAR*NOS*SOINS*************************** ************TOD4****DDP22********************************************************* ************************************·············································· ·················································································· ·················································································· ·················································································· ·································································LIN4000001······· ································· MACHE·BARQ.··FRA···················SA ·······················+000000000061390NT+000000001000KGM+000000000750+000000000046040········ ···········································IMD4F··············MACHE·BARQ.··FRA···· ·················································································· ··············································································TRIE VAT···································S··+0000005500······························ ·········TMA4+000000000048660································+000000000046120····· ··············································ALCEA··04··························· ···········TD·········································+000000000000000+0000021000· ························ FT*WPMT1·······TAUX·DE·REFERENCEMENT·DE·*********········· ·················································································· ·················································································· ·················································································· ································································ALCEC··02········· ·····························T*·········································+000000000 000080+0000000180······················ ···FT*WINV3·······CTIFL···························· ·················································································· ·················································································· ·················································································· ··········································································T*S4VAT· ··································S··+0000005500+000000000046120+000000000002540

Fin de l’extrait « Masqué »

7.77.77.77.7 SécuritéSécuritéSécuritéSécurité

Les règles minimales de sécurité attendues sont :

RG 34. Intégration aisée à l’outil de sauvegarde de LALLIER avec automatisation des opérations d’exploitation de type « sauvegarde » et « reprise sur incident »

RG 35. Il doit être interdit de créer / modifier / supprimer des données, formules et requêtes en dehors du cadre de l’administrateur LALLIER

RG 36. Il doit être possible en cas d’incident de réaliser une restauration des données soit sur le site central

RG 37. Une télémaintenance sera assurée dans la semaine ouvrée en fonction des horaires du prestataires

RG 38. Les statistiques sont prévues annelles et de ce fait la base doit être annuelle, ce qui implique la gestion des archives.

7.87.87.87.8 Garantie techniqueGarantie techniqueGarantie techniqueGarantie technique

Les logiciels prévus seront garantis classiquement six mois contre tout vice et défaut caché, en dehors des modifications du cahier des charges qui fera l’objet d’avenants spécifiques.

7.97.97.97.9 ValidationValidationValidationValidation



Les règles de validation sont identiques à celles du module « Mercuriales Clients ».

7.107.107.107.10 RecettesRecettesRecettesRecettes

Les règles de recettes sont identiques à celles du modules « Mercuriales Clients ». Le jeu de test et les outils de contrôle sont ceux décrits dans l’annexe et remis avec le présent document sous les références : « TEST_CTRL_CONSO »



8. Glossaire

Terme Définition Chef de file Partenaires chargé d’élaborer une mercuriale par client sur une région donnée. La répartition

géographique est définie par le client. Ainsi, sur chaque région définie, un chef de file est désigné par LALLIER pour un client donné.

Citrix Dispositif informatique permettant de partager des applications sur un serveur Excel Logiciel tableur de Microsoft permettant de réaliser des tableau* sous forme de feuilles de

calcul F&L Fruits et légumes Groupe Pilote Ensemble des partenaires chargés de tester les solutions mises en œuvre et d’émettre un avis

et des demandes de corrections d’après ses tests réalisés LS Liaison spécialisée, liaison informatique dédiée à un échange entre 2 points d’un réseau étendu Mailing List Liste de destinataires auprès de qui un courrier électronique doit être envoyé en automatique Maquette Produit informatique permettant de visualiser le produit final avant son achèvement, afin de

vérifier la présence des informations utiles, la bonne ergonomie, etc. Masqueur Logiciel permettant de lire un fichier EDI et de le réécrire (sous un autre nom) en masquant les

zones confidentielles par des caractères masquant (tel qu’une étoile ou un # par exemple) Mercuriale Document définissant, après négociation entre le chef de file et le client, le prix de vente

applicable pour ce client par les partenaires de la région travaillant avec ce client. Navision Logiciel d’ERP sur lequel l’ensemble de la nouvelle informatique de LALLIER s’appuie et

contenant les tables des « Produits » (F&L) ODBC Langage sous Windows permettant d’interroger des bases de données de format différent Partenaires Grossiste en fruits et légumes, adhérent à la centrale d’achat LALLIER-Fruits, et réalisant des

opérations d’achat de produits auprès de cette dernière. SQL Langage standard permettant d’interroger des bases de données de type « Relationnel » VA Vérification d’aptitude : signature du document de validation VABF, fin de cette dernière VABF Vérification d’aptitude au bon fonctionnement : période de contrôle de fonctionnement du

logiciel (utilisation réelle sans blocage, totalité des fonctionnalités disponibles) VSR Vérification de Service Régulier : vérification de conformité d’exploitation [temps réponse,

validité documents édités, automatisation, sécurité] � vérification par des tests de performance après la VA.

Windows NT Système d’exploitation (Machine et Réseau) de type 32 bits



9. Plan d’un Cahier des Charges

Il n’existe pas de schéma type d’un cahier des charges ; celui-ci va, en effet, varier en fonctions des objectifs, du produit, du public visé (interne, externe ciblé, appel d’offre, etc.). On peut par contre s’appuyer sur des trames telles que celles-ci pour obtenir un canevas de travail :

Canevas Simplifié d’un Cahier des charges pour une réinformatisation Ce canevas donne les grandes lignes à aborder (il est à adapter bien sûr) dans un tel cadre. Il peut donner à lieu à des développements particuliers si des domaines nécessitent des variantes. 1. Cadre du projet

1.1. Présentation de l’entreprise 1.2. Présentation des spécificités métier

2. Objectifs et objet du cahier des charges 2.1. Cadre général 2.2. Objet / Produit attendu 2.3. Objectif et limite du présent document 2.4. Domaines et objectifs par domaines 2.5. Projets et objectifs par projets

3. Rôles et acteurs 3.1. Acteurs internes 3.2. Acteurs externes 3.3. Organigramme et répartition des rôles

4. Existant (si besoin) 4.1. Système informatique 4.2. Système organisationnel 4.3. Données 4.4. etc.

5. Cadre matériel 5.1. Matériel 5.2. Réseau 5.3. Sécurité générale et spécifique 5.4. Systèmes spécifiques 5.5. Implantation géographique 5.6. Raccordement à l’existant 5.7. etc.

6. Cadre logiciel 6.1. OS 6.2. NOS 6.3. Outils généraux et spécifiques 6.4. Logiciels généraux et spécifiques 6.5. etc.

7. Cadre organisationnel 7.1. Cadre géographique 7.2. Cadre organisation interne 7.3. Cadre organisation externe (partenaires, sous-

traitants, etc.) 7.4. Flux d’informations et de documents 7.5. etc.

8. Cadre données 8.1. Modèle des données 8.2. Portées 8.3. Contraintes PICD 8.4. Implantation géographique 8.5. Outils et logiciels de gestions associées 8.6. Règles 8.7. Sécurité

9. Sécurité 10. Formation 11. Transitions

11.1. Données 11.2. Logiciels 11.3. Archives 11.4. etc.

12. Cadre contractuel 13. Cadre de validations

13.1. Principe général 13.2. Règles 13.3. Recettes intermédiaires 13.4. Recette finale 13.5. etc.

14. Cadre financier 15. Planning prévisionnel 16. Annexes



Canevas simplifié d’un cahier des charges pour un logiciel spécifique

1. Cadre du projet 1.1. Présentation de l’entreprise 1.2. Présentation des spécificités métier

2. Objectifs et objet du cahier des charges cf précédent

3. Rôles et acteurs cf précédent

4. Logiciel de … 4.1. Objectif 4.2. Organisation 4.3. Fonctionnalités 4.4. Système de données 4.5. Système des traitements (avec détail par

domaine) 4.6. Interfaces et IHM 4.7. Procédures exceptionnelles 4.8. Procédures et règles de sécurité 4.9. Procédures et règles d’exploitation 4.10. Procédures et règles d’installation 4.11. Implantation matérielle 4.12. Connexions et liens avec l’existant 4.13. Reprises des données existantes 4.14. Gestion des droits d’accès 4.15. etc.

5. Usage et exploitation 5.1. Usage et exploitation 5.2. Formation 5.3. Maintenance 5.4. Garantie 5.5. Évolution 5.6. Manuels (exploitation, installation, sécurité,

développement, maintenance, etc.) 6. Règles méthodologiques

6.1. Outils et méthodes

6.2. Sources (disponibilité, propriété, etc.) 6.3. Procédures associées 6.4. Règles Qualité 6.5. Normes 6.6. etc.

7. Données traitées 7.1. Modèle des données 7.2. Règles de gestion 7.3. Règles et droits d’accès 7.4. Règles de sécurité et contraintes PICD 7.5. Volumes 7.6. etc.

8. Sécurité 9. Validations

9.1. Principe 9.2. Règles 9.3. Mesures de performances et Benchmark 9.4. Tests 9.5. Recettes – VA (vérification d’aptitude) – VABF

(VA au bon fonctionnement) – VSR (Validation de Service Régulier) - …

9.6. etc. 10. Règles contractuelles

10.1. Propriété 10.2. Coûts 10.3. Garantie 10.4. Recours 10.5. Assistance 10.6. Hot Line 10.7. Conditions spécifiques 10.8. etc.

11. Règles financières 12. Planning prévisionnel 13. Annexes

Nota : Un CdC peut être composé de plusieurs éléments que sont:

• CCA : cahier des charges administratifs

• CCT : cahier des charges techniques ou CST : cahier des spécifications techniques

• CCR : cahier des charges de réalisation

• MAQ : manuel d’assurance qualité

• AO : appel d’offre



10. Maîtrise d’œuvre et d’ouvrage

Nous rappelons ici les définitions succinctes de ces deux acteurs primordiaux de tout projet et des actions et documents associés à un projet :

10.110.110.110.1 Maître d’ouvrageMaître d’ouvrageMaître d’ouvrageMaître d’ouvrage

C’est celui qui gère la commande du bien, il assure le suivi de réalisation, les contrôles, etc. cette maîtrise peut-être déléguée Dans un projet informatique, il fournit un ensemble de prestations et produits afin de pouvoir utiliser et tester

• interfaces, données • paramètres • personnel, locaux • etc.

On le définit comme la « Personne physique ou morale qui commande la réalisation du projet, conclut le contrat et reçoit l'ouvrage terminé ». En principe, le maître de l'ouvrage devient propriétaire au moment où il prend possession de l'ouvrage terminé. C’est aussi la « Personne physique ou morale pour le compte de laquelle sont effectués les travaux commandés par elle à l'entrepreneur » ou l’ « Organisme qui définit les objectifs et exprime les besoins au niveau global pour la réalisation d'un produit dont il assure le financement ». On parle dans ces cas là de maître de l’ouvrage ou de promoteur. Note : Pour toute opération d'investissement, tout maître d'ouvrage (État, département, commune, établissement public, etc.) doit, en principe, désigner en son sein un directeur d'investissement, et dans le secteur public un conducteur d'opération. En anglais, se dit : owner, project manager ou entrepreneur (pour promoteur).

10.210.210.210.2 Maître d’œuvreMaître d’œuvreMaître d’œuvreMaître d’œuvre

C’est celui qui réalise tout ou partie du produit fini ; il dispose d’un rôle précis définit par le client. Il travaille sur un lot défini ou sur la totalité du produit fini. Il peut utiliser des sous-traitants Il fournit des prestations et produits pour réalisation et mise en œuvre de :

• Organisation du projet • gestion planning, ressources, etc. • documents techniques • contrôles, essais, tests, etc. • contrôle qualité

On le définit comme la « Personne physique ou morale à qui le maître de l'ouvrage confie la direction ou le contrôle de l'exécution des travaux » ou l’ « Organisme responsable contractuellement de la maîtrise de toutes les activités nécessaires à la réalisation d'un produit, en particulier de la qualité, des délais et du prix ». C’est



en fait la « Personne physique ou morale qui est responsable de l'exécution de l'ensemble des travaux de construction ». On notera que dans certains cas le maître d'œuvre peut être le propriétaire. En anglais : prime contractor, principal contractor, main contractor. Note : Le titulaire d'un marché à qui l'on confie la conception du projet uniquement est le concepteur.

10.310.310.310.3 Cahier des chargesCahier des chargesCahier des chargesCahier des charges

Pour permettre au maîtres d’œuvre et d’ouvrage de travailler, il doit aborder et détailler au minimum 8 domaines :

• cadre client - demandeurs • spécification du projet et du produit demandé avec les objectifs et buts

attendus • spécifications techniques et/ou fonctionnelles • spécifications de mesure de réussite • planning prévisionnel et étude économique • étude contractuelle (parties engagées, obligations et devoirs, recours, etc.) • outils de mesure, contrôle et validation • règles de recettes

10.410.410.410.4 RRRRecettesecettesecettesecettes

Maître d’œuvre et d’ouvrage doivent s’entendre sur le principe retenu pour les recettes des lots et du produit fini ; pour cela, il faut savoir que : La recette correspond à la réception d’un produit avec période de contrôle et test pour validation de la conformité vis à vis d’une demande formalisée (CdC) Il existe diverses formes de recettes :

• Recette partielle ou intermédiaire • Recette provisoire • Recette globale • Recette définitive

En tout état de cause, les recettes sont :

• Liées à un contrat (interne ou externe) • Liées à des outils et des méthodes

Elles visent à :

• Assurance réciproque de bonne fin de travail • Accord basé sur 4 concepts

� les partie définissent règles et outils lors signature contrat avec CdC, � le séquencement de base d’une recette est le suivant :

• le réalisateur livre, • le client teste, • le réalisateur corrige, • le client valide,

� elles forment un élément contractuel formalisé et défini AVANT la signature,



� elles visent à réduire les litiges de manière significatives. Une recette informatique se définit ainsi : Étape de vérification d'un logiciel pour s'assurer qu'il est conforme aux spécifications. Que l’on traduit en anglais par : « validation » ou « technical approval ». Sur le plan technique, donc non spécifiquement informatique, on dit qu’une recette ou réception correspond à l’ « Ensemble des opérations conduisant au transfert de responsabilité ou de propriété d'un produit ». On dit « acceptance » en anglais.

10.510.510.510.5 Définition des documentsDéfinition des documentsDéfinition des documentsDéfinition des documents

10.5.1 Cahier des charges

C’est le « document établi par le demandeur définissant les clauses techniques, les clauses de qualité et les clauses administratives applicables à la fourniture recherchée; il sert de base à la proposition du fournisseur, et pourra faire l'objet d'un contrat ». Le cahier des charges n’est pas le cahier des spécifications techniques comme beaucoup de sociétés le croient ; en informatique, on confond trop souvent le CST et le CdC alors que le premier n’est qu’une partie du second. Pratiquement, le CdC amène à définir le CST. La définition formelle d’un CdC est la suivante : « Terme générique pour désigner un document rassemblant les obligations et les éléments nécessaires pour définir un besoin (traitement d'informations, méthodes et outils de travail, etc.) et les principales contraintes à respecter pour le satisfaire. » Note : Faute de document normalisé, on emploie divers documents tels que : note de principe, objectifs, plan-guide, schéma directeur, spécifications techniques ou simplement des notes internes, fiches descriptives, programmes de travail. En anglais : user requirements ou job instructions pour le CdC et specs pour le CST. Il existe d’autres types de cahier des charges ; voici deux définitions particulières :

• Le cahier des charges fonctionnel (CCF) : Document décrivant en termes de fonctions, de services ou de contraintes le besoin propre du demandeur ou celui qu'il est chargé de traduire.

• Le cahier des charges techniques (CCT) : Document contractuel complétant ou définissant les options prises parmi les libertés laissées par le cahier des charges ou modifiant celui-ci.

10.5.2 Appel d’offre

Techniquement, l’appel d’offre est une « Invitation à présenter une offre en vue de l'attribution d'un contrat » ; juridiquement, on parlera plutôt de « Procédure d'appel à la concurrence, par laquelle un acheteur éventuel de biens, de fournitures ou de



services invite un ou plusieurs fournisseurs à lui présenter des propositions précises en vue de l'attribution d'un marché ». En anglais, se dit : invitation to bid, call for tenders, call for bids, advertisement to bid, tender advertisement ou request for bids. Note : Dans le domaine des marchés publics, l'appel d'offres est dit « ouvert » lorsque toute entreprise intéressée peut remettre une offre; il est dit « restreint » lorsque seuls sont admis à remettre une offre les candidats que l'Administration a décidé de consulter. On étend ces appellations au cadre des marchés privés. Il existe d’autres formes particulières d’appel d’offre telles que :

• Appel d’offre sur concours : Appel d'offres lancé sur la base d'un programme établi par l'Administration qui indique les besoins à satisfaire, les contraintes et les exigences à respecter, et à partir duquel les candidats définissent le plus exactement possible les prestations qu'ils proposent pour répondre aux besoins indiqués. L'Administration fait habituellement appel à cette procédure lorsque des motifs d'ordre technique, esthétique ou financier justifient des recherches particulières. Le concours peut porter sur l'établissement d'un projet, sur son exécution ou sur les deux à la fois. En anglais : invitation for proposal

• Appel d’offre restreint : Appel d'offres caractérisé par une mise en concurrence limitée aux seuls candidats préalablement retenus par l'Administration. Cette procédure peut être précédée d'un appel de candidatures. Elle permet au maître de l'ouvrage, par exemple, de choisir les entreprises concurrentes et d'attribuer librement le marché de travaux. En anglais : non-competitive bid solicitation

• Appel d’offre ouvert : Appel d'offres caractérisé par la publicité d'une mise en concurrence et suivant lequel tout candidat admis à participer peut remettre une offre. En anglais : open tendering

10.610.610.610.6 GarantieGarantieGarantieGarantie

Il existe de très nombreux types de garantie (garantie de bonne fin, garantie de paiement, garantie bancaire, garantie de prix, de qualité, etc.). Seule la définition générale nous intéresse ici : Obligation légale ou contractuelle, imposée au vendeur, et qui assure l'acheteur de la bonne exécution d'engagement ou d'un service, de la qualité et du bon fonctionnement d'un bien ou d'une installation pendant une période donnée. Cette obligation tombe si l'acheteur fait un usage contraire aux spécifications techniques recommandées par le vendeur. La garantie peut être limitée, par exemple, au remplacement gratuit des pièces défectueuses. Elle est « totale » lorsque le vendeur prend en charge le remplacement des pièces défectueuses et le coût de la main-d’œuvre nécessaire à la remise en état.

10.710.710.710.7 MaintenanceMaintenanceMaintenanceMaintenance

La maintenance consiste en l’ensemble des activités et actions ayant pour but de maintenir ou de remettre une unité fonctionnelle (matériel ou logiciel ou réseau, etc.) dans un état lui permettant d'assurer son rôle. La maintenance comprend certaines opérations telles que : essais, mesurages, remplacements, réglages et réparations.



On considère que « maintenir », c’est, de manière générique, effectuer des opérations (dépannage, visite, réparation, amélioration, etc.) qui permettent de conserver le potentiel du système pour assurer la continuité et la qualité d’usage de ce système. On considère en principe cinq niveaux de maintenance :

1. Premier niveau : Réglages simples prévus par le constructeur au moyen d'éléments accessibles sans aucun démontage ou ouverture de l'équipement, ou échanges d'éléments consommables accessibles en toute sécurité. Ce type d'intervention peut être effectué par l'exploitant du bien, sur place, sans outillage et à l'aide des instructions d'utilisation. Le stock de pièces consommables nécessaires est très faible.

2. Deuxième niveau : Dépannages par échange standard des éléments prévus à cet effet et opérations mineures de maintenance préventive, telles que graissage ou contrôle de bon fonctionnement. Ce type d'intervention peut être effectué par un technicien habilité de qualification moyenne, sur place, avec l'outillage portable défini par les instructions de maintenance, et à l'aide de ces mêmes instructions. On peut se procurer les pièces de rechange transportables nécessaires sans délai et à proximité immédiate du lieu d'exploitation.

3. Troisième niveau : Identification et diagnostic des pannes, réparations par échange de composants ou d'éléments fonctionnels, réparations mécaniques mineures, et toutes opérations courantes de maintenance préventive telles que réglage général ou réalignement des appareils de mesure. Ce type d'intervention peut être effectué par un technicien spécialisé, sur place ou dans le local de maintenance, à l'aide de l'outillage prévu dans les instructions de maintenance ainsi que par des appareils de mesure et de réglage, et éventuellement par des bancs d'essais et de contrôle des équipements et en utilisant l'ensemble de la documentation nécessaire à la maintenance du bien et les pièces du magasin.

4. Quatrième niveau : Tous les travaux importants de maintenance corrective ou préventive à l'exception de la rénovation et de la reconstruction. Ce niveau comprend aussi le réglage des appareils de mesure utilisés pour la maintenance, et éventuellement la vérification des étalons de travail par les organismes spécialisés. Ce type d'intervention peut être effectué par une équipe comprenant un encadrement technique très spécialisé, dans un atelier spécialisé doté d'un outillage général (moyens mécaniques, de câblage, de nettoyage, etc.) et éventuellement de bancs de mesure et d'étalons de travail nécessaires, et à l'aide de toutes documentations générales ou particulières.

5. Cinquième niveau : Rénovation, reconstruction ou exécution des réparations importantes confiées à un atelier central ou à une unité extérieure. Par définition, ce type de travaux est donc effectué par le constructeur, ou par le reconstructeur, avec des moyens définis par le constructeur et donc proches de la fabrication.

1. cahier des charges - m.behe.free.frm.behe.free.fr/cours/l3/semestre_5/sie/tp/cdc_exemple.pdf ·...

Documents