TIERCE MAINTENANCE APPLICATIVE

Notre expertise au cœur de vos projets TIERCE MAINTENANCE APPLICATIVE SERVICE LEVEL AGREEMENT

Sommaire 1. Terminologie...4 1.1. Définitions...4 1.2. Abréviations...5 2. Missions & Objectifs...5 2.1. Missions...5 2.2. Objectifs...6 2.3. Gestion du Document SLA...6 2.4. Limitation du périmètre...6 3. Organisation...7 3.1. Organisation du «Fournisseur»...7 3.2. Organisation du «client»...7 3.3. Comités et réunions de travail...7 3.3.1. Comité de pilotage : COPIL...8 3.3.2. Comite qualité...9 4. Prestation...10 4.1. Nature des maintenances...10 4.2. Matrice de services...10 4.3. Pénalités de retard...11 4.4. Gestion des événements perturbant le projet...11 4.5. Respect des normes...12 5. Organisation de service - TMA au forfait...12 5.1. Prise en compte du besoin...12 5.1.1. Processus de prise en compte...13 5.1.2. Description du processus...14 5.1.3. Procédure de déclaration d une demande d assistance...14 5.2. Traitement d une demande d assistance...15 5.2.1. Processus de traitement d une demande d assistance...15 5.2.2. Description du processus de traitement d une demande d assistance...16 5.3. Maintenance corrective...17 5.4. Support applicatif...18 5.5. Maintenance évolutive mineure...18 6. Organisation de service - TMA sur bon de commande...19 6.1. Processus de conduite de projet...19 6.2. Description de la conduite de projet...20 6.2.1. Spécification technique des besoins...20 6.2.2. Découpage du projet...20 Page 2/14

6.2.3. Suivi du projet...20 6.3. Maintenance évolutive...20 6.4. Découverte des nouvelles applications...21 7. Gestion de la documentation...22 7.1. Le dossier de projet...22 7.2. La Documentation technique...22 7.3. La documentation des demandes d assistance...23 8. Phase de réversibilité...23 8.1. Objectifs...23 8.2. Tableau de charge...23 9. Moyens et services concernés...24 9.1. Lieu...24 9.2. Les moyens techniques...24 9.3. Les moyens humains...24 9.4. Répartition des demandes d assistance...24 9.5. Délimitation de la prestation...24 9.6. Engagements du «Fournisseur»...25 10. Conditions commerciales...26 10.1. Prix et financement...26 10.2. Bases économiques...26 10.3. Termes et conditions de paiement...26 Page 3/14

1. Terminologie Ce chapitre correspond à un glossaire lié à ce document. Les définitions qui suivent ne sont ni universelles, ni exhaustives, mais sont celles utilisées pour ce document et son périmètre d application. 1.1. Définitions «Client» Définition présente dans les Conditions Générales de Vente (CGV) «Fournisseur» Définition présente dans les Conditions Générales de Vente (CGV) «Key user» Personne appartenant à l organisation du «client» autorisée à réaliser et à valider les tests applicatifs sur une application donnée. «Composant technique» On entend par «composant technique» tout dispositif ou correctif logiciel mis en place dans l application. «Module spécifique» Il s agit d'un composant technique constitué d un programme exécutable développé par le «fournisseur» conformément au Cahier des Spécifications préalablement accepté par le «client» et ayant fait l'objet d'une recette définitive, à l issue des tests prévus, attestant que tous les objectifs fixés entre les deux parties ont été atteints. «Documentation de description» Il s agit d un document décrivant la composition d une version de l application, par un inventaire exhaustif des composants techniques entrant dans sa composition. «Documentation d utilisation» Il s agit d un document décrivant l usage d une version de l application, par une description du rôle et du mode opératoire de chaque fonction. «Documentation d exploitation» Il s agit d un document décrivant les opérations courantes nécessaires au fonctionnement régulier d une version de l application, par une description du rôle et du mode opératoire de chaque procédure d exploitation ainsi que par sa planification. «Anomalie» C'est au sein d un lot une erreur de programmation, de paramétrage ou d installation, ou un défaut de réalisation par rapport au référentiel documentaire applicable. Les sources émettrices d anomalies précisent les caractéristiques de l anomalie en distinguant son type (Bloquant, Majeur et Mineur) et en la classifiant selon un critère de fréquence (Fréquent, Systématique, Aléatoire). «Anomalie bloquante» C'est une anomalie rendant le logiciel indisponible du fait de l'impossibilité de son utilisation ou de celle d'une fonctionnalité jugée critique ou essentielle. Une anomalie bloquante concerne essentiellement un problème technique (plantage, arrêt des traitements). «Demande d évolution» Souhait de faire évoluer le logiciel par rapport à son référentiel documentaire applicable. Cette demande est formalisée par le biais d une demande écrite (Fiche de fait technique). «Solution de contournement» Solution apportée à une anomalie permettant la poursuite des traitements mais sans résolution de la cause réelle de l anomalie, exemples : utilisation d une autre procédure de l application permettant d aboutir au résultat désiré, modification ponctuelle d un programme pour traiter spécifiquement un ensemble de données, modification ponctuelle d un fichier qui permet la poursuite des traitements ; «Solution définitive» Correction apportée à la cause réelle d une anomalie. Page 4/14

1.2. Abréviations AO : Appel d offre BL : Bon de livraison CDP : Chef de Projet du Fournisseur CGV : Conditions Générales de Vente CP : Conditions Particulières du Contat CPM : Chef de Projet «client» COPIL : Comité de pilotage LORI : Acronyme de Logiciel des Opérations de Résolutions des Incidents. Outil de suivi des demandes d assistance TMA. PVR : Procès Verbal de Réception TL : Temps de livraison UO : Unité d oeuvre TPC : Temps de prise en compte TR : Temps de résolution TRT : Temps de résolution total TMA : Tierce Maintenance des Applications SLA : Service Level Agreement. PAQM :Plan d assurance qualité maintenance. Terme Français correspondant à SLA. 2. Missions & Objectifs 2.1. Missions L'objet du document SLA est de préciser les dispositions prises par le «fournisseur» pour répondre aux exigences de qualité portant sur le service fourni dans la Tierce Maintenance des Applications (TMA) autour des applications confiées. Il contient les modalités d'exécution du service. Ce document décrit ou référence les méthodes, les processus, l'organisation, tant internes au «Fournisseur» que celles avec les interlocuteurs du «client», et plus particulièrement l'ensemble des dispositions prises par le «fournisseur» pour fournir des prestations d'assistance, de maintenance et de nouveaux développements autour des applications Lotus Notes confiées en répondant aux besoins de qualité requis par le «client» dans le cadre du contrat de TMA. Ce document répond aux besoins spécifiques de la TMA. On y trouve regroupées les informations et règles utiles aux intervenants du projet : l'organisation du projet, la démarche de réalisation, les méthodes, outils et règles, les principes liés à la gestion de la documentation, à la gestion de la configuration, les modalités de livraison, les actions de communication, les contraintes minimales de temps de réponses des applications, les dispositions générales et particulières prises dans le cadre du projet pour le respect des normes, cadre réglementaire, normatif ou autres dispositions générales, la définition et les modalités de calcul des indicateurs de suivi de qualité du service Page 5/14

2.2. Objectifs Ce document présente l ensemble des procédures minimum à respecter par les prestataires en charge du projet TMA. Ce document répond à un impératif de formalisation : Il permet de définir le rôle des différents intervenants et instances de suivi et contrôle du projet, Il permet de définir le cadre réglementaire, normatif ou autres dispositions générales que le projet et ses livrables doivent respecter, Il décrit les principaux circuits de communication entre les différents intervenants, Il définit les normes de documentation et met à disposition des documents et formulaires types utilisés dans le cadre de ce projet, Il définit le plan de communication afin de garantir la bonne acceptation et le bon usage du projet auprès des différentes familles d intervenants, Il définit les indicateurs de base permettant de mesurer la qualité de la prestation des équipes de réalisation du projet. Ce document a pour objectif de mettre en place les procédures et l organisation nécessaire qui permettra d accomplir les objectifs que s est fixés le «client» sur cette TMA, à savoir : Amélioration de la qualité du processus Amélioration de la qualité des applications Amélioration de la qualité de service Garantie de réversibilité de compétences vers les équipes «client» à tout moment 2.3. Gestion du Document SLA Ce document constitue le Plan d Assurance Qualité ou Service Level Agreement pour la Tierce Maintenance Applicative. Il est identifié par la référence : ADI-SLA- 1.0, Il est proposé par le «fournisseur» qui en est le rédacteur. Toute évolution du Service Level Agreement doit recevoir l accord des deux parties, formalisé par décision du comité de Pilotage ou du comité Qualité. Le document Service Level Agreement peut évoluer sur proposition du «Fournisseur» ou du «client». La ou les évolutions devront être acceptées et validées par les deux parties. Au minimum, une réunion de suivi qualité sera tenue par an. Lors de cette réunion, un point sera fait sur la nécessité de faire évoluer le document SLA ou les conditions particulières du contrat associé. Cette réunion sera planifiée avec l équipe projet du «client» par le Chef de projet du «Fournisseur». 2.4. Limitation du périmètre Les limitations du périmètre sont définies dans les conditions particulières du contrat. Page 6/14

3. Organisation Ce chapitre a pour objet de fixer l organisation et les membres des équipes qui évolueront sur le projet. 3.1. Organisation du «Fournisseur» L offre de Support et de Tierce Maintenance Applicative du Fournisseur, est articulée autour de deux cellules : Une cellule de support (ou Hotline) Une cellule dédiée à la TMA du «client» La cellule de support, c est : 15 consultants expérimentés Un guichet unique pour l ensemble des technologies supportées par le «fournisseur» (ex : IBM, Microsoft, VMWare, Citrix, etc.) Un accès privilégié au plus haut niveau de support proposé par chacun des éditeurs et constructeurs 3500 appels par mois La garantie que tous les appels sont traités en temps et en heure La cellule TMA, c est : Une équipe d experts certifiés sur les technologies objet de la TMA L assurance d une réactivité maximum Des outils spécifiques de suivi et de gestion Un guichet unique sur le projet La cellule TMA, s appuie au quotidien, sur la cellule de support & maintien opérationnel pour optimiser la fiabilité des diagnostics en faisant appel à l ensemble des compétences techniques du «Fournisseur» (développement, infrastructure, matériel, etc). Cette organisation assurera au «client» une amélioration de la qualité du processus. En effet, la présence de ces deux équipes disponibles, assureront rigueur et simplicité dans le traitement des demandes d assistance du «client». Le «fournisseur» s engage à mettre à disposition une équipe de base stable et dont les compétences sont en rapport avec les prestations demandées. L équipe du «Fournisseur» est définie dans les conditions particulières du contrat. 3.2. Organisation du «client» Le «client» nomme un chef de projet qui sera l interlocuteur direct et unique du chef de projet «Fournisseur». Le «client» s engage à prévoir la disponibilité des bons interlocuteurs aux dates prévues dans le planning de façon à ce que les engagements contractuels et les objectifs de délais du projet soient tenus. L équipe des interlocuteurs «client» est définie dans les conditions particulières du contrat. 3.3. Comités et réunions de travail Ces différents comités et/ou réunions doivent permettre au «client» de vérifier l atteinte des 4 objectifs majeurs fixés dans le cahier des charges : Amélioration de la qualité des processus Amélioration de la qualité des applications Amélioration de la qualité du service Garantie de réversibilité de compétences vers le «client» à tout moment Page 7/14

3.3.1. Comité de pilotage : COPIL Un Comité de pilotage (COPIL) a lieu en fonction de la périodicité définie dans les conditions particulières du contrat. Il gère le contrat et ses évolutions et veille au bon déroulement des prestations. Il a un rôle opérationnel et il est unique pour toutes les Applications. Il veille au respect, par tous les acteurs, de l'ensemble des dispositions définies au contrat, par les conditions générales du contrat par le document SLA et par les conditions particulières du contrat. Son objectif est de garantir : Le bon déroulement des opérations Le respect général du contrat Une visibilité du plan de charge du projet de TMA La résolution des incidents dans une démarche d amélioration et de progrès Il doit répondre à deux attentes majeures du «client» : Amélioration de la qualité des applications Amélioration de la qualité de service Son rôle est de : Contrôler le fonctionnement global de la TMA (activités, risques, incidents, coûts) Définir l'évolution des besoins à moyen terme et la stratégie globale de la TMA Mesurer la satisfaction vis-à-vis de la prestation du titulaire Régler les situations exceptionnelles Prendre les décisions majeures Valider les devis et les avenants éventuels du contrat Analyser les tableaux de bord, graphiques et rapports de synthèse de la période en cours Suivre l avancement des prestations (compte rendu, planning, indicateurs, plan d actions) S assurer de l information et de la coordination des équipes Planifier et mettre en œuvre les changements décidés Préciser les évolutions majeures des applications et produits utilisés Analyser les problèmes rencontrés et aider à les résoudre (solution ou plan d actions) Valider le portefeuille et le planning des corrections issues des demandes et de leur mise en production Effectuer les arbitrages et définir les priorités Il est initialisé (composition et première réunion) suite à la réunion de lancement, lors de la phase d Initialisation. Les livrables : Rapport d activité Compte-rendu rédigé par le CDP «fournisseur». A défaut de réponse dans les 5 jours ouvrés, ce compte-rendu est réputé approuvé par le client. Une fois approuvé, le compte-rendu a un caractère contractuel. Les participants côté «client» Le responsable du marché Le chef de projet Les key users des applications à l ordre du jour Des invités selon l ordre du jour Les participants côté «fournisseur» Le chef de projet Le responsable de compte, si des validations ou présentation de devis sont à l ordre du jour Des invités selon l ordre du jour Lieu Dans les locaux du «client» ou du «fournisseur». Fréquence Page 8/14

Défini par les conditions particulières du contrat. Un email de confirmation sera envoyé au Responsable de projet «client» par le responsable de projet «fournisseur», deux semaines à l avance avec l ordre du jour et les participants souhaités. 3.3.2. Comite qualité Un comité qualité aura lieu périodiquement (fréquence précisée aux CP). Le rôle de ce comité qualité est de : Vérifier le respect par les différents acteurs du document SLA Décider des évolutions du document SLA et ou des conditions particulières dans une démarche d amélioration du service Présentation du calcul des pénalités de retard Présentation des enquêtes de satisfaction Mesurer l amélioration de la qualité du processus Vérifier et mesurer la qualité de la documentation afin de garantir la réversibilité des compétences vers les équipes «client» à tout moment Les demandes d évolutions seront présentées par le Responsable Qualité du «fournisseur». Ces demandes devront lui être transmises 15 jours avant la tenue du comité par les différents chefs de projet. Documents en sortie : Nouvelle version du document SLA. A défaut de validation dans les 5 jours ouvrés, la nouvelle version du PAQM est réputée approuvée par le «client». Document de calcul des pénalités de retard Enquête de satisfaction Les participants côté «client» Le chef de projet Le responsable qualité Le responsable du marché, si nécessaire Les participants côté «fournisseur» Le chef de projet Le responsable qualité Le responsable de compte, si nécessaire Lieu Dans les locaux du «client» ou de «fournisseur». Fréquence Au début du 12 ème mois de l anniversaire du contrat. Un email de confirmation sera envoyé au Responsable de projet «client» par le responsable qualité «fournisseur». Page 9/14

4. Prestation 4.1. Nature des maintenances Ce chapitre présente les différentes typologies de maintenance que l on pourra trouver au cours de la TMA, ainsi que leur champ d application. UO 1 Phase d initialisation L objectif principal lors de la phase d initialisation de la T.M.A. est d assurer la prise de connaissance technique et fonctionnelle de l existant, à savoir les applications décrites dans les conditions particulières du contrat. UO 2 Maintenance corrective / Support applicatif Les prestations de maintenance corrective portent sur des interventions de type correctif dans les environnements de production. Ces interventions consistent à corriger toute anomalie de fonctionnement détectée dans les programmes, la documentation, et autres composants de l'application. Cette UO comporte également les aspects de support applicatif (voir 6.4) que la cellule TMA dispensera aux key users. Cette maintenance se fait de manière forfaitaire. UO 3 Maintenance évolutive Les demandes de maintenance évolutive sont soumises par la remise d un cahier des charges de la part du «client» au «fournisseur». Cette maintenance se fait sur bon de commande. UO 4 - Maintenance évolutive mineure Ce sont les demandes de maintenance évolutive dont la charge de travail est inférieure ou égale au nombre de jours défini dans les conditions particulières du contrat. Cette maintenance se fait de manière forfaitaire. UO 5 Phase de réversibilité Il s agit de définir les conditions dans lesquelles le «fournisseur» organise le transfert de compétences vers toute personne habilitée par le «client», afin de leur permettre de poursuivre la maintenance de l application au même niveau de qualité. Ces différentes natures de maintenance mettent en évidence deux types contractuels de maintenance : TMA au forfait TMA sur bon de commande 4.2. Matrice de services Chaque application peut être dotée d un niveau de criticité. De plus, chaque demande d assistance (DA) fera également l objet d une qualification sur son niveau de gravité. Ces deux paramètres permettent d établir la matrice de service présentée dans les conditions particulière du contrat Cette matrice de service permettra de fixer les différents délais à mesurer de la prise en compte à la résolution totale d un incident dans le cadre de la maintenance corrective. Pour garantir au «client» le respect de ces différents délais et la qualité des réponses apportées, deux organisations de services seront mises en place : Organisation de services pour la TMA au forfait Organisation de services pour la TMA sur bon de commande Page 10/14

4.3. Pénalités de retard Lorsque la résolution d une demande d assistance ne satisfera pas les objectifs fixés dans la matrice de services, un calcul des pénalités de retard pourra être demandé par le «client» lors d un Comité de pilotage. Le «fournisseur» s engage sur un système de pénalités basé sur le délai de livraison du correctif. Ce délai possède également l avantage de simplifier les responsabilités en cas de dépassement du délai. De plus, cet engagement montre également la volonté du «fournisseur» de s engager fortement dans une démarche de qualité et de respect des engagements dans ce projet de TMA. Ces pénalités sont appliquées par catégorie de pénalité (4 catégories : catégorie 1, 2, 3, 4) selon le tableau ci-dessous : Délai de livraison du correctif ou de la solution de contournement Type d incident Niveau de criticité de l application Bloquante Majeure Mineure Bloquant 1 1 3 Majeur 2 2 4 Mineur 3 4 4 Méthode de calcul : Chaque DA est comptabilisée par catégorie de pénalité Si plus de 80% des DA pour une catégorie de pénalité donnée ont été réalisés en conformité avec la matrice de services alors aucune pénalité ne sera demandée par le client. Le montant de la pénalité par catégorie sera de 2,5 % du montant total HT du contrat (hors montant relevant d heures de télé consulting ou de journées prépayées). Fréquence de mesure : Annuelle Date de début d application des pénalités : Les 3 premiers mois de la TMA seront sans application de pénalités. La 1ère année, il est entendu que la première mesure sera effectuée sur 9 mois à l issue de la période sans pénalité. 4.4. Gestion des événements perturbant le projet Le «fournisseur» a mis en place au sein de sa cellule de support, une mécanique de déclenchement d alerte et d escalade au travers d une fonction : Le manager de supervision. Cette personne a pour fonction, au travers des outils utilisés par la cellule Support et la cellule TMA du «fournisseur», de surveiller l avancement mais surtout le respect des délais sur chaque déclaration d incidents. Cette fonction permet de surveiller en permanence les facteurs qualités afin de garantir le respect des engagements auprès du «client». Cette surveillance, dans le cas de la TMA s opère sur trois niveaux : Le respect du temps de prise en compte d une DA (voir processus de prise en compte) Le respect du temps de livraison d un correctif sur une DA Le respect du temps de correction totale d un DA Ce processus automatique d escalade prévoit les points suivants : Une DA est déclarée par le «client» auprès de la cellule support ; Si bloquante, le manager de supervision affecte directement la DA à une personne de la cellule TMA ; Si majeure ou mineure, le manager de supervision sera alerté automatiquement par email si une heure avant l échéance, la DA n a toujours pas été prise en compte. A ce moment-là, c est le manager de supervision qui affecte la DA à une personne de la cellule TMA ; Si personne n est disponible, la DA est affectée au chef de projet ; Page 11/14

Si le chef de projet n est pas disponible, une alerte est remontée au Responsable Qualité de la TMA pour action immédiate et information au client de la situation ; Une fois la DA affectée, le manager de supervision prend en charge le suivi des autres mesures ; Comme pour le suivi de la prise en compte de la DA, une escalade à deux niveaux est prévue, une première auprès du chef de projet et une seconde auprès du responsable qualité ; Ces alertes sont déclenchées en fonction des objectifs de la matrice de services ; Le manager de supervision a à sa disposition, un tableau de bord en temps réel qui lui permet de surveiller ces différents objectifs. En complément de ce dispositif d escalade automatique, le «client» pourra à tout moment déclencher une procédure EVENEMENT auprès du Responsable Qualité pour signaler un dysfonctionnement dans le déroulement de la TMA. A réception de cette procédure EVENEMENT, une analyse sera faite par le Responsable Qualité sur le dysfonctionnement signalé. Dans les 2 jours ouvrés suivant le déclenchement de la procédure EVENEMENT, le Responsable Qualité s engage à revenir vers le Chef de projet «client» avec un plan d action visant à corriger le dysfonctionnement. Afin de faciliter le déclenchement de ce type de procédure, un simple email du chef de projet «client», mentionnant en objet FICHE EVENEMENT à destination du Responsable Qualité «fournisseur» suffira. Cet email devra au minimum contenir les informations suivantes : Dysfonctionnement technique, contractuel ou relationnel Le ou les applications concernées, si nécessaire Une description précise du dysfonctionnement Une description précise de l attente 4.5. Respect des normes Les contraintes concernant le respect de certaines normes devront être décrites dans les conditions particulières du contrat. 5. Organisation de service - TMA au forfait 5.1. Prise en compte du besoin La demande d assistance est matérialisée par une action de la part du «client». Cette action peut se faire sous la forme d un appel téléphonique, de l envoi d un mail à la cellule support ou d une déclaration sur notre outil de suivi LORI au moyen d un accès Internet sécurisé. Le numéro de contrat d assistance devra être précisé quel que soit le moyen utilisé. La demande d assistance sera prise en compte du lundi au vendredi de 8h30-09h00 à 18h00-18h30 selon le niveau de maintenance retenu (hors jours fériés). Page 12/14

5.1.1. Processus de prise en compte Page 13/14

5.1.2. Description du processus Chaque demande d assistance, téléphonique ou email, fait l objet de l ouverture d un dossier d appel (log) dans l outil de suivi des demandes d assistance du «Fournisseur». Ce dossier est affecté ensuite à la cellule TMA. Ce dossier d appel contient : La date et heure de la demande L objet de la demande L urgence de la demande Le nom du demandeur Une fois affecté à la cellule TMA, ce dossier d appel est converti en déclaration d incident dans l outil LORI du «Fournisseur» et affecté immédiatement à une ressource de la cellule, qui devient le responsable de l incident. Le responsable de l incident va : Catégoriser l incident Affecter, à l aide de la matrice de service, un degré de criticité et de priorité. Affecter un statut de prise en compte à l incident. Estimer le temps de correction et de livraison L email de prise en compte est alors envoyé au demandeur. L incident rentre alors dans la file d attente de traitement. Afin de faciliter et réduire la charge dans les phases de tests, l incident pourra être intégré à un lot regroupant d autres incidents sur la même application afin de n effectuer qu une batterie de tests lors de la livraison. 5.1.3. Procédure de déclaration d une demande d assistance Le «client» devra suivre les procédures de déclaration de demande d assistance suivantes auprès du «Fournisseur» Par téléphone : Appeler le 04 66 68 71 08 (Cellule Support du «Fournisseur») Indiquer à la personne du support son identité et préciser que l appel est dans le cadre de la «TMA» Indiquer le nom de l application pour laquelle il appelle Indiquer de manière claire et synthétique la description de son problème Indiquer si son problème est reproductible (dans le cadre de la maintenance corrective) : Toujours / Parfois sous condition connue / De manière aléatoire / jamais Indiquer la priorité du sa demande (Critique / Majeure / Mineure) NB : Dans la cadre de demande de support, il devra indiquer s il souhaite être rappelé ou contacté par email. NB2 : Seuls les Key users (ou leur suppléant) pourront ouvrir des demandes d assistance Par email : Rédiger un email à destination de : tma@grouperdi.com Indiquer en objet, le nom de l application (utiliser les abréviations décrites en page 10) et la criticité (Critique / Majeure / Mineure) de la demande en utilisant la convention suivante : o [nom de l application] criticité de la demande o Ex : [SAV]Mineure Dans le corps de l email, indiquer de manière claire et synthétique la description de son problème, y ajouter si possible des impressions écrans ou tous documents pouvant étayer ses explications Indiquer également si son problème est reproductible (dans le cadre de la maintenance corrective) : Toujours / Parfois sous condition connue / De manière aléatoire / jamais NB : Dans la cadre de demande de support, il peut indiquer dans son email s il souhaite être rappelé. Si aucune indication n est faite, alors il recevra une réponse par email). Par LORI (Web) : Se connecter à l adresse suivante : http://lori.grouperdi.com/tma Page 14/14

NB : Un manuel utilisateur LORI est disponible dans LORI ou sur simple demande par email à tma@grouperdi.com 5.2. Traitement d une demande d assistance 5.2.1. Processus de traitement d une demande d assistance Page 15/14

Suivi des demandes Rapporteur Développeur / Chef de projet Rapporter demande Etat = nouveau Analyser demande Ajout de commentaire client Si besoin compléments Changer l état en En pause Etat = En pause Si ok Etat = en pause Changer l état en pris en charge Changer l état en pause Etat = pris en charge Si ok Si non ok Analyser proposition solution Si ok Changer l état en en traitement Etat = Non résolu Réouvrir demande Si non ok Etat =en traitement Changer l état en livré Etat = livré Tester Changer l état en recette Si ok Etat = recette Changer l état en fermé Etat = fermé 5.2.2. Description du processus de traitement d une demande d assistance Page 16/14

Une fois la prise en compte réalisée, le processus de traitement de la demande démarre. Toutes les phases de ce traitement, qui sont décrites dans le processus précédent, sont enregistrées et consultables pour tous les acteurs du projet dans l outil LORI, dont des accès par web seront fournis au «client». Une fois le correctif développé et testé en environnement de développement, l équipe IT du «client» est informée par un email de la cellule TMA de la livraison du correctif. Cet email fera référence au n de déclaration, à l application concernée et contiendra la procédure d installation. Le key user de l application est ensuite informé de la livraison du correctif sur la plateforme de qualification par l équipe IT du «client». Le key user procède aux tests et en donne les résultats dans LORI. Si les tests sont concluants l incident est fermé. Dans le cas contraire une nouvelle note sera ajoutée dans la déclaration d incident et le key user passera la demande en «Non Résolu». Le fait de marquer chaque étape du traitement des demandes d assistance permettra aux chefs de projet de produire des indicateurs de mesure de la qualité du service. 5.3. Maintenance corrective Les prestations de maintenance corrective portent sur des interventions de type correctif dans les environnements de production. Ces interventions consistent à corriger toute anomalie de fonctionnement détectée dans les programmes, la documentation, et autres composants de l'application. La maintenance corrective consiste à prendre en charge l intégralité des anomalies de fonctionnement de l application et à apporter des solutions adéquates selon le processus suivant. Acteurs Action Temps de résolution Client Qualification par le «client» du niveau de gravité de l anomalie constatée : Bloquant, Majeur, Mineur Client Déclaration de la demande d assistance par le «client» au «fournisseur» Début du décompte du TPC* Fournisseur Confirmation de la prise en compte de l incident et de sa qualification Fin du décompte du TPC Début du décompte du TL** Début du décompte du TRT*** Fournisseur Identification des causes du problème, formalisation d un diagnostic ainsi que d une ou des solutions Fournisseur Mise en œuvre de la correction, test unitaire et de non-régression en environnement de développement Fournisseur Livraison des correctifs et de la procédure d installation. Cette livraison est Fin du décompte du TL assortie d'un PV de réception. Client Installation des correctifs dans l environnement de qualification Client Test des correctifs sur la plate-forme de qualification Client Recette fonctionnelle et validation du correctif (Validation du PVR) Fournisseur Clôture de l incident dans LORI Fin du décompte du TRT Client Installation du correctif dans l environnement de production Fournisseur Conseil et assistance lors des tests dans l environnement de qualification et de production Fournisseur Mise à jour de la documentation technique *TPC : Temps de prise en compte **TL : Temps de livraison *** TRT : Temps de résolution total La prise en charge de l anomalie, la livraison du correctif (1) ainsi que la résolution définitive de l anomalie (1)(2) (en dehors des délais de validation par le «Client») devront respecter les délais liés à la gravité de l anomalie. (1) Hors temps de pause (2) Le délai de résolution définitive hors délais de validation client correspond au délai de dernière livraison. Le décompte du délai imparti au «Fournisseur» pour résoudre une anomalie ne court que pendant les jours et heures ouvrables soit du lundi au vendredi de 9h à 18h. Page 17/14

S il ne peut être procédé immédiatement à la correction des applications, une solution de contournement peut être proposée au «client» et mise en œuvre avec son accord. Livrable(s) : les composants de la version corrigée de l application documentation d installation PV de réception 5.4. Support applicatif En complément de la maintenance corrective, le «fournisseur» se propose de réaliser un support applicatif de niveau 2 aux équipes en charge de la TMA côté «client». En effet, l expérience du «fournisseur» sur ce type de TMA montre que très souvent les demandes d anomalies sont des «faux», à savoir, plus un manque de connaissance des capacités de l application qu un problème technique nécessitant une résolution. En intégrant ce type de support dans le forfait de la TMA, le «fournisseur» s engage aux côtés du «client» pour aider au mieux les utilisateurs clés du «client» dans l utilisation de ses applications. Ce support peut par exemple : Mettre à contribution un développeur pour réaliser une analyse du code afin de savoir si l application peut répondre à telle ou telle demande. Aider un key user dans des problèmes fonctionnels de validation d étapes sur un workflow. Assister un key user sur la mise en place de nouveaux processus fonctionnels au sein d une application etc. Ce support applicatif, comme la maintenance corrective, sera suivi au travers d indicateurs opérationnels et d indicateurs de pilotage. 5.5. Maintenance évolutive mineure Les demandes de maintenance évolutive mineure sont soumises par la remise d une expression du besoin au CDP. Après étude du besoin et questions éventuelles au «Client», la demande est qualifiée techniquement et quantifiée au niveau de la charge. Si la charge est estimée supérieure au nombre de jours défini dans les conditions particulières du contrat, alors la demande est basculée en Maintenance évolutive. Tous ces éléments sont repris dans un document de spécifications techniques des besoins qui sera envoyé au «client» pour validation. Après accord du STB, les demandes d évolution mineure font l objet d un processus allégé : Définition d un planning de réalisation en accord avec le «Client» Réalisation des développements, test unitaire sur environnement de développement Livraison, tests sur l environnement de qualification par le «client» Recette et validation du PVR par le «client» Installation sur l environnement de production par le «client» Remise de la documentation Eléments pris en compte dans le calcul de la charge : Analyse du besoin Rédaction du STB Développements Tests sur environnement de développement Documentation Page 18/14

6. Organisation de service - TMA sur bon de commande Dans cette partie de la TMA, la prise en compte se fait par le chef de projet, lors de la réception d un cahier des charges. Ce cahier des charges fait l objet d une étude par la cellule TMA et le chef de projet envoie au client une proposition commerciale sur la réalisation demandée. L organisation mise en place pour répondre, est une organisation classique de gestion de projet avec des phases claires et précises, du cahier des charges à la réception définitive. 6.1. Processus de conduite de projet Page 19/14

6.2. Description de la conduite de projet 6.2.1. Spécification technique des besoins Les spécifications techniques des besoins sont un document d interprétation technique de la proposition commerciale réalisée en début de projet. Il constitue un document contractuel d enrichissement de la proposition commerciale. Il permet de : Bien cadrer le projet technique, en accord avec la proposition commerciale Détailler les UO de réalisation Fixer un planning sur le projet C est le document de référence, pour le «client» et pour le «Fournisseur», pour justifier de la bonne réalisation et du périmètre du projet. A l issue des STB, des éléments non détectés dans la proposition commerciale peuvent être identifiés. La conséquence peut être la modification des UO du planning et peut être aussi des modifications du contrat si nécessaire. 6.2.2. Découpage du projet Le projet est découpé en «Phases», représentant les grandes étapes du projet (Infrastructure, Gestion, Développement). Chacune de ces phases est découpée en «Unité d Œuvre» (UO). Ces UO définissent un ensemble de tâches cohérentes pouvant être recettées ensemble ou indépendamment des autres. Ce découpage permet d avoir tout au long du projet des points de livraisons intermédiaires qui permettent un suivi concret de l avancement du projet. Chaque livraison fait l objet d un PV de réception sur l UO concernée. Exemple : Phase : Développement d'un workflow de demande de congés UO 1 : Développement du workflow UO 2 : Développement du moteur de déversement des congés dans l outil RH UO 3 : Développement d un intranet de consultation des soldes de congés UO 4 : Test et Validation solution finale 6.2.3. Suivi du projet Un chef de projet est nommé sur chaque dossier. Il est l interlocuteur unique pour le «client» sur le dossier en question. Il coordonne l ensemble des pôles services du «Fournisseur» amenés à intervenir. Des comptes rendus réguliers sur l avancement du projet seront fournis aux membres du comité de pilotage (document écrit transmit par e-mail), accompagnés de réunions téléphoniques si nécessaire. Des réunions seront effectuées avec le «client». Leurs fréquences seront définies en fonction des besoins de chaque partie et du planning projet (validation UO, besoin spécifique, etc.). Ces réunions seront des comités de pilotage, elles s effectueront en présence du «client». A l issue de chaque réunion un compte rendu sera rédigé par le chef de projet du «Fournisseur» et transmis sous un délai de 3 jours aux membres du comité de pilotage. 6.3. Maintenance évolutive Les demandes de maintenance évolutive sont soumises par la remise d un cahier des charges. Après étude du cahier des charges, et questions éventuelles au «Client», le «Fournisseur» soumet une proposition financière. Les délais de remise de ces devis sont variables selon la complexité des demandes : Evolution simple : sous 2 jours Evolution moyenne : sous 3 jours Page 20/14

Evolution majeure : sous 5 jours Une fois le devis validé, la prise en charge se fera sous un délai négocié avec le «client». Après accord de la proposition financière, les demandes d évolution «simples» font l objet d un processus allégé : Le STB est inclus dans l offre commerciale Définition d un planning de réalisation en accord avec le «Client» Réalisation des développements, test unitaire sur environnement de développement Livraison, tests sur l environnement de qualification Recette et validation du PVR Livraison sur l environnement de production Remise de la documentation En ce qui concerne les évolutions de type «moyenne» ou «complexe», la procédure est la suivante : Rédaction par la cellule TMA d un STB détaillé, tant sur les aspects fonctionnelles que techniques Validation par le «Client» du STB avant toute autre action Définition d un planning détaillé de réalisation en accord avec le «Client» Réalisation des développements et puis test unitaire sur environnement de développement Fourniture par le «Client» d un jeu d essais Livraison, tests sur l environnement de qualification Fourniture de la procédure d installation ainsi que du cahier de recette Assurer la formation nécessaire à la prise en main de l évolution (pour les évolutions «complexes») Recette fonctionnelle jusqu à validation de l évolution et émission du PV de réception définitif Livraison de la documentation associée nécessaire. Quel que soit le niveau, la réalisation de la prestation ne pourra débuter qu après validation de la proposition financière et émission d un bon de commande. L exécution des travaux proprement dite débutera après : La validation par le «client» des Spécifications Techniques des Besoins (STB) pour les évolutions moyennes et complexes La mise en place d un planning satisfaisant les deux parties, en particulier sur l aspect vérification de fonctionnement/recette Livrable(s) : Offre commerciale Spécifications Techniques des Besoins (évolution complexe) Les composants de la nouvelle version, notamment les programmes sources La mise à jour de la documentation associée à l application Formation et/ou documentation utilisateur (si demandé) PV de réception 6.4. Découverte des nouvelles applications Lors d une déclaration d un incident sur une application non prise en compte dans le périmètre initiale, le «fournisseur» mettra en application la procédure qui suit pour réaliser la prise en charge de cette nouvelle application. La procédure de prise en compte est la suivante : Mail du chef de projet «fournisseur» au chef de projet «client» pour obtenir l aval de prendre en charge l application. Mise en œuvre sous une semaine d une procédure de découverte qui tiendra sur une fourchette de 1 à 5 journée(s). NB : Tant que l application n est pas prise en compte, la matrice de services sera gelée sur l application concernée. Cette procédure de découverte allégée comprendra les tâches suivantes : o Découverte fonctionnelle : 40% (1) de la charge. o Découverte technique : 40% (1) de la charge. o Rédaction documentation technique et fonctionnelle : 20% (1) de la charge. (1) Pourcentage indicatif soumis aux caractéristiques particulières des applicatifs Si une application présente une complexité ou un périmètre exceptionnel, une procédure adaptée peut être mise en place avec l accord des chefs de projet «fournisseur» et «client». Livrable : PV de prise en compte de l application Page 21/14

Dépose de la documentation dans LORI. Proposition d amendement des conditions particulières du contrat émise par le Responsable Qualité «fournisseur» au responsable de projet «client». Charge : 1 à 5 jour(s) au tarif applicable dans l offre commerciale. 7. Gestion de la documentation Toute la documentation du projet sera gérée dans l outil LORI. Cette documentation se répartit en trois grandes familles : Le dossier de projet La documentation technique des applications La documentation des demandes d assistance 7.1. Le dossier de projet Le dossier de projet est géré par le «fournisseur» et stocké dans l espace de stockage du groupe de travail dans l outil LORI. Le dossier de projet contient : Le cahier des charges L offre commerciale Les documents nécessaires à la gestion du projet, émis ou reçus par le projet, comme les plannings, les comptes-rendus, les courriers, etc.... Le document SLA Les tableaux de bord et indicateurs 7.2. La Documentation technique La documentation technique de chaque application est gérée durant toute la période du contrat par le fournisseur. Elle sera suivie en numéro de version et stockée dans l outil LORI. Elle comprend la liste des documents suivants : Document Cahier des charges Dossier de recette Dossier de conception technique générale Fiche application Dossier de spécifications Manuel de référence ou utilisateur Dossier d installation et d exploitation Description du contenu attendu Il doit décrire l objet à produire Il formalise la recette du produit Il décrit globalement la solution technique choisie pour répondre au cahier des charges Il s agit d une ou deux pages pour décrire plus particulièrement les fonctionnalités d une application Il détaille la solution technique choisie, l environnement de développement, l architecture et l organisation interne du logiciel, le modèle physique des données, les interfaces, les fonctions et les règles associées, les normes de codage, etc. Chaque processus du système est modélisé. Cette documentation est générée en partie automatiquement par nos outils de développements. Il donne le mode opératoire de toutes les fonctions et de toutes les règles de gestion expliquées dans le détail, menu par menu, écran par écran. Il permet aux informaticiens d installer et de mettre en œuvre le produit. Il doit aussi d écrire ce que font les exploitants. Lors de la prise en main d une application entrant dans la TMA, le bilan de prise de connaissance de l application devra mentionner l absence ou la présence du contenu de chacun des documents de cette liste en indiquant le nom du document et où l information se Page 22/14

situe. Il indiquera également la qualité et la valeur opérationnelle des informations mises à disposition dans le cadre de la phase d initialisation. Les documents définis ci-après devront être présentés au «client» soit pour information, soit pour acceptation. Ils entrent dans la constitution d un dossier final et seront présentés sous forme lisible, en langue française, au format électronique. Chaque auteur de document est chargé de son identification en respectant la règle d unicité de l identifiant parmi les documents du projet. La diffusion des documents pourra être faite via fichiers informatiques, communiqués par mail, support mémoire ou en téléchargement à partir de LORI. Format de diffusion des documents électroniques : PDF ou MS Office. Le fournisseur s engage à minimum à livrer à la fin du contrat la documentation de conception technique et fonctionnelle de chaque application. Cette documentation sera réalisée lors de la phase d initialisation et amender tout au long de la vie du contrat. Un indicateur qualité permettra de suivre cet enrichissement. 7.3. La documentation des demandes d assistance Chaque demande d assistance fera l objet d un document électronique consultable dans LORI. Si nécessaire, d autres documents, comme des imprimes écrans, pourront être joints à la demande d assistance. 8. Phase de réversibilité 8.1. Objectifs Il s agit de définir les conditions dans lesquelles le «fournisseur» organise le transfert de compétences vers toute personne habilitée par le client, afin de leur permettre de poursuivre la maintenance de l application au même niveau de qualité. Cette mission de transfert de compétences comprend l organisation de sessions de travail sur les domaines suivants : architecture applicative, architecture technique, environnements de développement, de tests et de formation, description de l organisation de la documentation de référence, communication des éléments statistiques et indicateurs des 6 derniers mois information sur les demandes d anomalies en cours et récentes 8.2. Tableau de charge Le tableau des charges est décrit dans les conditions particulières du contrat. En option, le «fournisseur» se propose d installer l environnement de «bug tracking» LORI chez le «client», pour que celui-ci puisse disposer instantanément de tout l environnement de suivi et l historique de la maintenance réalisée. NB : Pas de coût logiciel associé à LORI. Livrable(s) : les comptes rendus des réunions de transfert de compétences PV de recette-transfert de compétence Cette fourniture de service est optionnelle et par bon de commande La mission de transfert de compétences débute à la réception du bon de commande émis par le client. Le délai d'exécution ne pourra excéder 1 mois. Page 23/14

9. Moyens et services concernés 9.1. Lieu Les prestations se déroulent depuis les locaux du «fournisseur». Les réunions et des interventions ponctuelles peuvent avoir lieu sur le site du «Client». 9.2. Les moyens techniques Pour le traitement des demandes d assistance le prestataire utilisera les environnements de développement du «client» via une connexion réseau VPN respectant les consignes de sécurité du client. Le «client» fournit les moyens d accès nécessaires via une liaison réseau sécurisée (connexion distante, autorisation d accès, etc. ) à ses différentes plates-formes de développement, de pré production et de production. Le «fournisseur» propose l utilisation d un outil permettant un accès distant sécurisé : TeamViewer Il permet d effectuer un support à distance à la demande, simple d'utilisation, sécurisé et rapide. 9.3. Les moyens humains Le projet sera pris en charge par un Chef de Projet «fournisseur», ayant une forte expérience du pilotage et de la gestion de projet. Le «fournisseur» s engage à mettre à disposition une équipe de base stable et dont les compétences sont en rapport avec les prestations demandées. Nos équipes de TMA intègrent des experts infrastructures pour optimiser le diagnostic des anomalies. Pour la bonne marche du projet, et compte tenu des échanges nécessaires lors des phases de validation, il est indispensable que le «client» nomme un chef de projet qui sera l interlocuteur direct et unique du chef de projet «fournisseur». De même concernant les validations des aspects fonctionnels et techniques, il reste de la responsabilité du «client» de prévoir la disponibilité des bons interlocuteurs aux dates prévues dans le planning de façon à ce que les engagements contractuels et les objectifs de délais du projet soient tenus. 9.4. Répartition des demandes d assistance La répartition des demandes d assistance devra respecter la volumétrie suivante : 3% de demandes bloquantes 12% de demandes majeures 60% de demandes mineures 25% de demande en évolutifs mineurs 9.5. Délimitation de la prestation Ne font pas partie de la prestation : La sauvegarde des données, L exploitation des plates-formes, Les performances liées à une infrastructure existante, L acquisition de logiciels de base ou applicatifs L acquisition de plateformes hardware Dans le cadre de cette prestation le «fournisseur» pourra faire des préconisations d architecture ou de modalités de fonctionnements au client. Si le client continue à effectuer des modifications et des améliorations sur les applications objet du marché, il s engage à documenter et à mettre à jour le référentiel. Le «fournisseur» ne peut être tenu pour responsable des anomalies dans les cas ci-après : mauvaise interprétation des fonctionnalités, exploitation incorrecte, Page 24/14

défaut de formation des utilisateurs. 9.6. Engagements du «Fournisseur» Le «fournisseur» s engage principalement sur les points suivants : Amélioration de la qualité du processus Amélioration de la qualité des applications Amélioration de la qualité de service Garantie de réversibilité de compétences vers le «client» à tout moment Amélioration de la qualité du processus : Visibilité complète du service par la mise à disposition d un outil et d indicateurs temps réel, LORI, accessible en mode web par le «client» Engagement sur la mise à disposition d un guichet unique qui supporte l ensemble des technologies présentes dans l environnement concerné par la TMA => Facilité & pertinence des diagnostics Engagement sur la stabilité de l équipe de TMA, par la mise à disposition sur la durée du contrat, de consultants séniors et d un chef de projet ayant une ancienneté significative chez le «Fournisseur», La proximité des services permettra, lorsque nécessaire, de faire intervenir le chef de projet et le responsable qualité du «Fournisseur» directement sur site afin de simplifier la communication Engagement sur un processus simple et automatique d escalade sur évènement. Accès bilingue (anglais français) à notre cellule ; Dans le cadre des TMA sur bon de commande, engagement sur une méthodologie projet éprouvée avec un respect des délais de livraison. Amélioration de la qualité des applications Trois axes d engagement sur cet objectif. Engagement sur la maîtrise documentaire : o Référencement complet de toute la documentation existante o Enrichissement de cette documentation lors de la phase d initialisation o Engagement sur la tenue de cette documentation au fil des développements Cet engagement sera mesuré au travers d un indicateur. Cette mesure mettra en rapport le nombre de corrections d incident sur une application et le nombre de modifications apportées à la documentation Engagement sur la diminution des incidents d exploitation o Engagement de proposition régulière de maintenance adaptative, grâce à nos relations privilégiées avec les éditeurs qui nous permettent de connaitre les road map produits. Engagement sur l amélioration de la performance des traitements o Respect du délai de prise en compte des incidents selon la matrice de service o Engagement sur la mise à disposition de ressources expérimentées dans les environnements techniques mis en œuvres. o Respect des délais de résolutions des incidents selon la matrice de service, o Respect des délais de correction totale selon la matrice du «Client». o Disponibilité de la cellule support de 8H00 à 18H30. o Optimisation des résolutions d anomalies par la constitution d une base de connaissances éprouvée, documentée et maîtrisée ; Amélioration de la qualité de service Engagement de proposition de maintenance préventive. Engagement de mesure de la qualité des rapporteurs, pour identifier des actions de formations éventuelles. Une tenue annuelle d une réunion qualité pour définir de nouveaux objectifs sur la qualité de service Page 25/14

Garantie de réversibilité Voir 8 Engagements complémentaires : Ouverture d accès de la cellule TMA par un outil en ligne 24/24H, par mail à une adresse unique, par téléphone sur un numéro local. Suivi en ligne des indicateurs clés sur la résolution des incidents [nombre de DA ] 10. Conditions commerciales 10.1. Prix et financement Voir les conditions particulières du contrat 10.2. Bases économiques Voir les conditions particulières du contrat. 10.3. Termes et conditions de paiement Voir les conditions particulières du contrat. Page 26/14