Dans cette section je vous décris mon expérience au sein de la SSII Sopra.
Je suis entrée chez Sopra en tant que stagiaire en février 2008
et suis embauchée en tant qu'ingénieur depuis juin 2008.

Le contexte du stage

Après mon expérience de 18 mois au sein de la start up Vaziva Conseil, je recherchais une structure de grande taille me permettant d'évoluer dans un univers plus ouvert :

• Possibilité d'évoluer vers les métiers fonctionnels
• Diversité et envergure des projets
• Méthodologies éprouvées et axées démarche qualité
• Proximité avec des experts dans des domaines spécifiques

J'ai dès lors décidé d'axer mes recherches dans le secteur des SSII. Après mes entretiens chez Logica, Steria et Sopra Group, j'ai décidé de rejoindre Sopra Group dont la philosophie se rapprocher le plus de mes besoins.

C'est donc au sein de la division secteur publique que j'ai signé pour mon stage de fin d'études. J'ai intégré une jeune équipe où mon premier projet était la mise en place d'une application de gestion de projets entre Sopra Group et l'AP-HP, Extraweb.

Les projets réalisés

ExtraWeb

Le client

Assistance Publique - Hôpitaux de Paris

Le projet

Extraweb est une application de gestion web qui offre une vision globale et précise de l’avancement des projets prise en charge par Sopra group.

Cette application comprend deux types d'utilisation :

• Les chefs de projet Sopra Group
• Paramétrage
• Profils et utilisateurs ;
• Domaines d’intervention et applications ;
• Tarification (par le biais d’unités d’œuvre classées par activité).
• Gestion / suivi
• Cahiers de charges
• Propositions commerciales (création des phases, étapes, livrables, UO)
• Bons de commande
• Sélection des phases, étapes, livrables
• Suivi du planning, des recettes, de la VA et VSR etc.
• Bons de livraison
• Facturation
• Règlement
• Les clients et équipes Sopra Group
• Suivi général et précis des projets(centralisation des documents généraux, description formalisée des projets, avancement, refus etc.)
• Reporting (Export Excel) global pour les comités de pilotage trimestriels

Mes réalisations

• Recueil des besoins
  C’est à partir des conditions générales CCAP et CCTP… que j’ai réalisé le recueil des besoins de la future application.
• Maquettage
  J’ai pris en charge le maquettage de l’application. Un long travail a du être réalisé sur l’enchaînement des écrans. Pas moins de 80 écrans ont été nécessaires à couvrir l’essentiel des fonctionnalités. Je me suis attachée à réaliser un réel travail sur l’ergonomie de l’application. Cette maquette a été réalisée en html, javascript et css.
• Spécifications fonctionnelles
  C’est en binôme que les spécifications fonctionnelles ont été rédigées. En effet S. SALANE est arrivé à ce moment sur le projet. Je lui ai dans un premier temps transmis mes connaissances, mes différentes études et ma vision de la conception fonctionnelle du projet. Nous nous sommes ensuite réparti les différentes briques fonctionnelles afin d’en rédiger les spécifications détaillées.
• Spécifications techniques
  L’architecture logicielle a été prise en charge par le chef de projet qui avait l’expérience de ce type de projet. Il nous a bien entendu expliqué pas à pas la méthodologie, la mise en place de chaque framework et l’environnement utilisé.
  C’est une nouvelle fois en binôme avec S. SALANE que nous avons réalisé le MCD (Modèle Conceptuel de Données), le MPD (Modèle Physique de Données) et enfin la création de la base de données.
• Dossier de qualification
  Toujours en binôme avec S. SALANE, j’ai réalisé le dossier de qualification qui avant la recette servira de référence pour les tests fonctionnels.
• Développement
  J’ai réalisé l’implémentation de deux modules dans leur entièreté (paramétrage des marchés et gestion des cahiers des charges) et participé à celle d’autres plus complexes tels que la gestion des propositions commerciales.
  J’ai effectué seulement 4 semaines de développement dont 2 semaines consécutives. En effet, j’ai très vite été appelée à réaliser les études fonctionnelles d’autres projets.

Images du projet

Bilan

Ce premier projet au sein de la SSII Sopra Group m’a permis d’intégrer une équipe avec laquelle je continue à travailler. Il m’a également permis de découvrir et de me familiariser avec les méthodes et procédures internes de Sopra Group.

Ce projet m’a entièrement satisfaite : une équipe intelligente et dynamique, un travail enrichissant aussi bien sur le plan fonctionnel que technique.

Sur le plan technique :
Lors de mon arrivée sur ce projet, je n’avais pas de réelle expérience industrielle dans le domaine du développement J2EE. Mes seules expériences ayant été jusqu’à lors la réalisation de travaux pratiques durant mes études.
Ce stage a donc été particulièrement enrichissant sur ce point, même si je n’ai effectivement travaillé sur la partie technique que 4 semaines.
La manipulation sur la base de données au travers de l’outil « Toad » et la complexité du modèle de données à réaliser m’a permis de renforcer mes connaissances dans le domaine des « Système de Gestion de Bases de Données ». J’ai d’ailleurs pu remarquer à quel point la modélisation des données était centrale et décisive pour la suite du développement.

Sur le plan fonctionnel :
J’ai pu acquérir la méthodologie et les savoirs faire de Sopra Group. J’ai découvert et travaillé sur 3 types de documents, les spécifications fonctionnelles générales, les spécifications fonctionnelles détaillées et le dossier de qualification.
J’ai également découvert les règles et procédures des projets des marchés publiques. Ce projet me permettra donc à l’avenir d’appréhender la gestion de mes futurs projets dans ce secteur.
Enfin, ce projet m’a donné l’occasion d’affirmer mon projet professionnel et de mettre en avant mes capacités à le réaliser. En effet, la réalisation de sa conception fonctionnelle a été décisive :

 j’ai rapidement été appelée à sortir du projet lors de la phase d’implémentation pour réaliser d’autres études fonctionnelles.

 Pour de plus amples détails sur ce projet : Présentation (format word)
 Exemple d'un document de spécifications fonctionnelles : Création d'une proposition commerciale (format word)

Suivi des indications pour le CEDIT

Le client

Le client de cette avant vente était le CEDIT (Comité d'Evaluation et de diffusion des innovations technologiques

Le CEDIT est une agence hospitalière d'évaluation de technologies médicales. Créé en 1982, le CEDIT est chargé de formuler des avis au Directeur général de l'Assistance Publique-Hôpitaux de Paris (AP-HP) sur l'opportunité, l'ampleur et les modalités de diffusion des innovations technologiques dans les établissements de l'AP-HP.
Le domaine d'expertise du CEDIT concerne les technologies médicales qui regroupent les matériels et procédures de prise en charge diagnostiques et thérapeutiques utilisés par les professionnels de santé dans la délivrance des soins aux individus et les systèmes dans lesquels les soins sont délivrés.

Le projet

Application s'intégrant à PHEDRA permettant la gestion des indications dans le cadre de la nouvelle loi sur la tarification à l'activité.

PHEDRA est une application permettant la gestion des spécialités pharmaceutiques et des dispositifs médicaux utilisés dans le cadre des soins pratiqués dans les centres de l'AP-HP (ensemble des prescriptions).
PHEDRA fournit un composant additionnel permettant le suivi des indications mais ses fonctionnalités ne couvrant l'ensemble des besoins, le CEDIT recherche une solution alternative mieux adaptée à ses processus métier.
Les pharmaciens du CEDIT doivent gérés l'ensemble des spécialités et dispositifs en fonction de la Tarification à l'Activité (T2A), le mode de financement des établissements de santé français issu de la réforme hospitalière du plan Hôpital 2007, qui vise à médicaliser le financement tout en équilibrant l'allocation des ressources financières et en responsabilisant les acteurs de santé.

Les différentes interviews réalisées auprès du personnel CEDIT et PHEDRA nous a permis de définir les objets suivants :

• Indications
• DCI, dénomination commune internationale (famille de spécialités ne comprenant pas la marque)
• Spécialités
• LPP, liste produits et prestations (famille de DM)
• DM, dispositif médical
• Journaux officiels
• Groupes (reconnaissance des indications)
• Utilisateurs et profils d'utilisateurs

Mes réalisations

• Recueil des besoins
  La phase la plus complexe de mon travail se trouvait dans le resueil des besoins.
  En effet, c'était la première fois que l'équipe cliente commandait une application informatique.
  Le besoin n'était pas du tout définit et, pour moi, le jargon utilisé a rendu difficile la compréhension de celui-ci.
• Maquettage
  J'ai très rapidement définit une première maquette, comme première base de travail lors de la seconde réunion.
• Etude comparative
  Afin de démontrer la valeur ajoutée de la solution proposée par Sopra Group, j'ai réalisé une étude comparative traitant des aspects métier, ergonomique et technique.
• Spécifications fonctionnelles
  A venir.

Images du projet

 Pour de plus amples détails sur le projet et mes réalisations : Présentation (format word)

TAXPRO

Le client

L'Association nationale pour la formation professionnelle des adultes (AFPA) est un organisme français de formation professionnelle.
Depuis les dernières années et en relation étroite avec l'ANPE, l'AFPA réaffirme sa place d'organisme de service public. À ce titre, elle contribue pleinement aux travaux du service public de l'emploi et participe aux nouvelles « maisons de l'emploi » dans certains départements.

Le projet

Il s'agissait du lot 2 de l'application TAXPRO permettant l'édition des déclarations de taxe professionnelle.

L’AFPA doit élaborer deux déclarations de taxe professionnelle par an :

• Une déclaration de modification (1003 P) qui doit être préparée en novembre – décembre de chaque année et servant de base d’imposition pour N+1
  Cette déclaration concerne uniquement les modifications des établissements (ouvertures, fermetures, ou changements d’adresse) au cours de l’année N
• Une déclaration définitive (1003) concernant toujours l’exercice N et qui doit être préparée en mars – avril N+1 de chaque année et sert de base d’imposition pour N+2
  Cette déclaration concerne touts les établissements qui ont une activité lucrative (environ 200 déclarations)

Les déclarations de taxe professionnelle sont produites aujourd’hui au niveau national pour l’ensemble des établissements de l’AFPA. Il a été demandé en 2007 la mise en place d’un nouvel outil permettant la décentralisation des déclarations au niveau des directions régionales de l’AFPA.
Ainsi, un premier lot de cette nouvelle application, LOT1 de TAXPRO, a été mis en production début 2008.

Le LOT2 doit s’articuler sur le LOT1 qui a été livré en production début 2008, et sera composé comme suit :

• LOT2.1 : mise en place des traitements dans la nouvelle application au niveau national et régional
• Traitements de contrôle de cohérence et d’exhaustivité des données
• Traitements de calcul au niveau national et au niveau régional avec la possibilité donnée aux utilisateurs de lancer de manière autonome les traitements de leurs régions
• Traitements pour la gestion des fermetures et ouvertures des saisies au niveau national et régional (donner la possibilité au niveau national et régional d’effectuer des simulations de contrôle)
• Traitements de consolidation, validation et préparation à l’émission manuelle des déclarations fiscales
• LOT2.2 :
• Traitements d’éditions des déclarations fiscales
• Archivage des données après fermeture définitive de l’exercice fiscal
• Tableau de contrôle final (provision au bilan, dégrèvement etc.)

Mes réalisations

• Recueil des besoins
  Le lot 1 étant déjà en production et un lourd cahier des charges ayant été fournit par la MOA, j'ai, dans un premier temps, commencé par une prise de connaissance du besoin. TODO...
• Maquettage
  J'ai réalisé la maquette tout au long de la rédaction des spécifications fonctionnelles.
• Spécifications fonctionnelles
  J'ai eu à charge la rédaction des 5 spécifications fonctionnelles détaillées. Le travail a été difficile étant m'a méconnaissance du métier et la complexité des données du système. TODO...
• Modélisation des données
  Afin de pouvoir lancer rapidement le projet, j'ai modélisé les données à partir de la première version de la base et avec l'aide du chef de projet présent à l'origine de l'application.
• Transmission de connaissance

Images du projet

Gestion des avis, autorisations et agréments

Le client

L'Agence de Biomédecine est un établissement public à caractère administratif qui intervient dans 4 grands domaines d'activités : la transplantation d'organes, de tissus et de cellules, la procréation, de l'embryologie et de la génétique humaine.
Créée dans le cadre de la révision des lois de bioéthique du 6 août 2004, elle a repris depuis le 10 mai 2005 les missions de l’Établissement français des Greffes. Son autorité de tutelle est le ministère de la Santé.

Le projet

Il s'agissait de mettre en place un outil de workflow pour la gestion des avis, autorisations et agréments des praticiens et établissements.

Il nous a été imposé l'utilisation de la suite BPM Workey que nous devions intégrer dans leur SI en utilisant leur intranet et leur base référentielle.

La suite BPM Workey est une solution de Business Process Management. Elle offre les fonctions nécessaires pour une mise en œuvre d’applications de workflow dans un environnement Web.
Workey est une solution développée pour les utilisateurs et orientée utilisateurs, aussi bien pour la conception du workflow (processus et formulaires) que pour l’utilisation des applications de workflow produites par workey.
Workey se base sur la méthode OSSAD (méthode d'analyse d'organisation par les processus).
La méthode de travail Workey est centrée sur l'utilisateur. En effet celui-ci doit être actif dans tout le processus de modélisation des processus. Workey comprend un designer qui peut être manipulé avec le client lors d'ateliers de conception.

Les 4 modules de Workey :

• Workey Designer est la solution pour analyser, modéliser, documenter et publier vos processus métier, formulaires, règles et connecteurs. La méthode OSSAD, intégralement supportée par l’outil, permet d’aborder vos projets de Business Process Management comme un projet d’organisation.
• Workey Admin propose une interface 100% WEB pour déployer, administrer sur le serveur, les différentes versions des processus modélisés. L’administration peut être centralisée ou décentralisée à l’aide d’une gestion fine des profils.
• Workey Engine permet d’orchestrer l’ensemble des processus de l’entreprise préalablement modélisés à l’aide de Workey Designer. L’ensemble des éléments de la modélisation sont automatisés afin d’obtenir des applications de workflow immédiatement opérationnelles sans aucun développement.
• L’interface web proposée en standard par Workey permet de proposer à chaque utilisateur préalablement authentifié une interface simple et intuitive pour créer, suivre ses processus et accéder à des tableaux de bord.

Les principes OSSAD

Ces six principes constituent une synthèse de la philosophie ossadienne.

• Participation Un projet ossadien ne doit pas se contenter de consulter les utilisateurs, il doit les associer continuellement à la démarche. Cette association s'appuie sur la clarté des concepts utilisés et leur apprentissage rapide par les participants. Elle est garante de leur motivation et de leur implication.
• Pragmatisme Un projet ossadien veut déboucher sur une solution réaliste et applicable à un problème bien identifié. Il ne s'agit pas de modéliser pour le plaisir.
• Expérimentation Un projet ossadien doit intégrer l'essai, par prototypage technique et organisationnel, des solutions envisagées sur le papier.
• Itérativité Un projet ossadien n'est pas linéaire. Des remises en question sont possibles et souhaitables dans les limites d'une gestion rigoureuse du projet, notamment lors de la validation des modèles par les participants.
• Agrégation Un projet ossadien vise à traiter des problèmes particuliers, à leur niveau de pertinence, sans perdre de vue l'ensemble de la situation. C'est une démarche de type systémique.
• Contingence Un projet ossadien s'organise autour du problème examiné et ne doit pas obligatoirement faire appel à tous les outils et techniques d'OSSAD qui, de plus, peuvent être adaptés si nécessaire.

Mes réalisations

• Recueil des besoins
  C'est en utilisant la méthode Workey que j'ai réalisé le recueil des besoins avec une collègue de la division business consulting. En effet, nous avons animé un ou deux ateliers par processus avec l'équipe MOA. Nous manipulions le produit en direct avec les utilisateurs pour produire le squelette de ces processus.
• Conception des workflow
  Lors d'ateliers avec l'équipe cliente, j'ai eu en charge, avec une collègue consultante, la conception des processus, procédures, opérations, connecteurs, formulaires etc.
• Intégration de la charte graphique
• Spécifications fonctionnelles
  
• Modélisation des données
  Modélisation de la base stockant les avis, autorisations et agréments selon les données intégrées dans l'application de workflow et la base référentielle de l'agence.
• Mise en place de développements spécifiques
• Transmission de connaissance à un collègue arrivé en fin de projet
• Qualification (rédaction du dossier et test)

Images du projet