Rapport de Stage Eureka BAZZAR V2 [PDF]

Zitiervorschau

MASTER INTELLIGENCE ECONOMIQUE Parcours : Analyse, Management des Données et Innovation

Rapport de Stage Strictement Confidentiel

Développement d’une plateforme numérique de management de l’innovation

Étudiant : Ader BAZZAR Resp. Académique : Karim FRAOUA, PhD

Tuteur d’entreprise : M. Sylvain CLEMENT Chef Projet : Kevin NJIFENJU, PhD

1er Mars 2020 - 31 Août 2020

Résumé Dans le cadre du développement d’un outil de management de l’innovation destiné aux PME et TPE, le cabinet de conseil en innovation EURÊKA C.I a entrepris des travaux de développement d’une application web dénommée RDI MANAGER. Ce stage a contribué à la construction des bases techniques de développement de cette plateforme collaborative de management de l’innovation. Nous avons en particulier défini les spécificités techniques et fonctionnelles de cette plateforme, en tenant compte des enjeux de management de l’innovation au sein des PME et TPE ; conçu l’architecture de la base de données et initié le développement de la plateforme. Ensuite, nous avons émis les bases de l’intégration du modèle d’intelligence artificielle et la plateforme, ainsi que son système d’alertes et notifications mobiles.

Remerciements Je tiens tout d’abord à remercier toute l’équipe EURÊKA C.I qui m’a accueilli en son sein et m’a permis de réaliser ce stage, qui fut d’un grand enrichissement technique et socioprofessionnel. Je citerai en particulier Kevin NJIFENJU le directeur du cabinet, dont les conseils techniques et socio-professionnels me seront bien utiles dans la suite de ma carrière ; et Sylvain CLEMENT qui a su m’encadrer et me pousser à aller vers l’information, tout le long du stage. Je n’oublierai pas l’équipe RDI Manager (Fleury et Yanny), ainsi que tous les collègues du site de SQY (Marie-France, Fouzia, Alain). Je tiens également à remercier l’ensemble des enseignants et e personnel administratif de l’institut Francilien d’Ingénierie des Services (Université Gustave Eiffel). Je cite en particulier le responsable du Master Intelligence Économique, Karim FRAOUA pour son accueil au sein du Master et ses conseils durant l’année ; ainsi que Olivier JARRAR pour son cours de Data Mining que j’ai particulièrement apprécié. Je remercie enfin mes camarades de l’université Gustave Eiffel, et en particulier la promotion Covid-19 de notre Master pour les moments conviviaux passés ensemble et la solidarité en stage-confiné du fait du coronavirus Covid-19 .

Table des matières 1 Introduction Générale 2

3

EURÊKA C.I et le projet RDI Manager 2.1 Le cabinet EURÊKA C.I . . . . . . . . . . . . . . 2.1.1 Les principales missions conseil du cabinet 2.1.2 Enjeux d’innovation au sein des PME . . . 2.2 Le Projet de Stage : RDI Manager . . . . . . . 2.2.1 État du marché . . . . . . . . . . . . . . . 2.2.2 État de l’art . . . . . . . . . . . . . . . . .

3 Conception technique de la plateforme 3.1 Spécifications de l’application . . . . . 3.1.1 Spécifications fonctionnelles . . 3.1.2 Spécifications techniques . . . . 3.2 Modélisation des scénarios nominaux . 3.2.1 Diagrammes de cas d’utilisation 3.2.2 Diagrammes de séquences . . . 3.3 Conception architecturale de la BDD .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

6 . 6 . 7 . 9 . 10 . 11 . 15

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

20 20 20 24 25 25 28 30

4 Développement de la plateforme 4.1 Charte graphique . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Développement des interfaces graphiques . . . . . . . . . . . . 4.3 Intégration des composants associés . . . . . . . . . . . . . . . 4.3.1 Intégration de la base de données . . . . . . . . . . . . 4.3.2 Approche envisagée pour la gestion des notifications . . 4.3.3 Approche envisagée pour l’intégration du module d’I.A 4.4 Approche envisagée pour le déploiement . . . . . . . . . . . . 4.5 Illustration des développements réalisés . . . . . . . . . . . . . 4.5.1 Parcours utilisateur back-office . . . . . . . . . . . . . . 4.5.2 Parcours utilisateur front-office . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

34 34 35 37 37 37 38 38 38 42 44

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

5 Conclusion Générale 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Références Bibliographiques : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Appendices

51

1

Table des figures 2.1 2.2 2.3 2.4 2.5 2.6

Organigramme de la société . . . . . . . . . . . . . . . . . . . L’offre de conseil EURÊKA C.I [7] . . . . . . . . . . . . . . . Analyse des produits concurrents sur le marché . . . . . . . . Positionnement de RDI Manager vis-à-vis de la concurrence Analyse SWOT de la plateforme RDI Manager . . . . . . . . . Principaux modèles de base de données, inspiré de [10, 3] . . .

. . . . . .

. . . . . .

7 8 13 14 14 17

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13

Tableau des acteurs back-office et leurs descriptions fonctionnelles . . . . . Tableau des acteurs front-office et leurs descriptions fonctionnelles . . . . . Rôles, attributions et droits des acteurs-utilisateurs Front & Back office . . Présentation modulaire des fonctionnalités RDI Manager . . . . . . . . . . Scénarios de gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . Scénarios de gestion des sociétés . . . . . . . . . . . . . . . . . . . . . . . Les scénarios de gestion des projets . . . . . . . . . . . . . . . . . . . . . . Scénarios de suivi des temps . . . . . . . . . . . . . . . . . . . . . . . . . . Illustration de la séquence de connexion d’un Observateur . . . . . . . . . Illustration d’une séquence de modification des informations société . . . . Illustration d’une séquence d’activation de compte utilisateur front-office . Illustration d’une séquence de visualisation de faits marquants d’un projet La Base des données RDI MANGER, établie sur MySql Workbench . . . .

. . . . . . . . . . . . .

21 21 22 23 26 26 27 27 28 29 30 30 32

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Logo RDI Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . Couleurs du site web EURÊKA et de l’application RDI MANAGER Architecture MVC du framework Symfony . . . . . . . . . . . . . . Proposition diagramme de déploiement RDI MANAGER . . . . . . Chemin des fonctionnalités back-office . . . . . . . . . . . . . . . . Chemin des fonctionnalités front-office . . . . . . . . . . . . . . . . Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . Interface d’ajout de société . . . . . . . . . . . . . . . . . . . . . . . Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contenu du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . Interface de saisie de temps RDI . . . . . . . . . . . . . . . . . . . . Interface de saisie des jours d’absences . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

34 35 36 39 40 41 42 42 43 43 44 44 45 46 46

1

Tâches principales effectuées au stage . . . . . . . . . . . . . . . . . . . . . . 52

2

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

Chapitre 1 Introduction Générale Dans la vie courante comme dans la vie professionnelle, mener à bien un projet suppose d’avoir une approche efficace de gestion du projet. L’enjeu principal de la gestion de projet est l’élimination des risques d’échec du projet. Ceci à chacune de ses étapes. Au début de l’ère de l’outil informatique (années 60 à 80), la gestion de projets se faisait à l’aide d’outils basiques tels que des tableurs de type Excel. Il s’agissait alors d’une simple transposition des informations notées sur des feuilles de papier, vers des fichiers informatiques plus ou moins élaborés. Cette approche de gestion de projet simple, était novatrice et satisfaisante. D’ailleurs beaucoup de particuliers, et même quelques entreprises (TPE) utilisent encore cette approche de nos jours. En effet, suivant la taille du projet, les enjeux de sa structuration, et le temps qu’on est prêt à consacrer pour sa gestion ; une approche de gestion de type tableur Excel peut être largement suffisante pour mener à bien le projet. Au début des années 80, la gestion de projet se professionnalise progressivement avec le développement des logiciels de gestion de projet évolués. Ces logiciels intègrent dans un seul et même outil numérique, toutes les dernières approches de gestion de projet : - Planification - Budgétisation - Analyses de toutes sortes (Gant et autres) - Suivi opérationnel - Suivi budgétaire, ... etc. À cette époque, le projet est piloté par un chef de projet, qui centralise toute l’information, la traite et communique aux autres parties prenantes du projet lors des réunions dites de revue de projet. Au début des années 2000, la démocratisation d’Internet et l’essor des réseaux d’entreprises de type Intranet, apportent de nouvelles possibilités dans la gestion de projet : l’accessibilité de l’information et la fluidité de ses échanges via les réseaux numériques. De ce fait le pilotage et le suivi de projet s’envisage de manière collaborative et encore plus sophistiquée. C’est l’ère du développement des plateformes numériques de gestion des projets en mode software as a service (SaaS). Les éditeurs de logiciels se lancent alors dans une course vers la digitalisation des processus de gestion de l’entreprise : les projets proprement dits, les processus de production, les processus d’administration, les processus de commercialisation et autres, sont désormais tous gérés comme des projets via des plateformes collaboratives. Ceci nous amène à l’émergence d’outils de gestion de projets hyper-performants et sophistiqués. Il en est de même pour les outils de gestion de l’entreprise de plus en plus complets (les ERP : Entreprise ressource Planning). Dans cette dynamique de développement de technologies numériques de management 3

Université G. Eiffel Rapport de Stage M2 de l’activité, deux problèmes intrinsèquement liés émergent progressivement. Ceux-ci sont relatifs à cet engouement vers la numérisation du management : — D’une part, on observe que les spécificités des différents domaines d’activités imposent des approches spécifiques dans le développement des logiciels de management. Ceci a eu pour conséquence la complexification des logiciels développés qui ambitionnent de tout couvrir dans tous les domaines d’activité. Dans le cas de développement des logiciels sectoriels, on a toujours affaire à des solutions complexes, car ces dernières veulent prendre en compte toutes les fonctionnalités du management dans le domaine d’activité considéré. — D’autre part, on note également l’hyper-sophistication de nombreux logiciels, dans le souci de fournir le maximum d’information possible. Le cas courant est la densification de la collecte d’information à l’échelle micro (échelles des collaborateurs de terrain et du middle-management), afin de fournir une information macro à l’échelle décisionnaire (le top management). Ces problématiques ont rendu l’utilisation de ces outils de management de projet particulièrement contraignants pour les collaborateurs. Or vu l’importance de ces informations pour la prise de décision, il est capital dans certaines sociétés (et en particulier pour le top management ou les chefs de projet), que les collaborateurs utilisent avec diligence ces logiciels de management de l’activité. En effet, dans une société qui compte plusieurs niveaux hiérarchiques (grands groupes et ETI par exemple), il est important d’avoir une approche efficace et structurée de management de l’activité (ou des projets). Et ceci quel que soit le coût induit par cette démarche. D’une telle approche structurée de management de projet, dépend parfois la réussite du projet ; ce qui dans la plupart des cas représente des enjeux stratégiques et financiers nonnégligeables. Dans des sociétés relativement petites (PME et TPE), bien que l’échelle hiérarchique soit réduite et que les échanges d’information entre les collaborateurs et les décisionnaires soit plus fluide ; la question de la gestion efficace et structurée de l’activité est aussi d’un enjeu financier non-négligeable. Cependant, utiliser un outil numérique, bien que structurant, mais très contraignant pour manager ses projets, représente un coût (en ressources humaines) difficilement acceptable. Dans ces cas spécifiques, il est nécessaire d’avoir des logiciels de suivi et de pilotage de l’activité (de projet) plus simples, ergonomiques et intelligents. Ceci afin de répondre aux besoins de structuration, d’efficacité et de performance auxquels ont aussi droit les PME et TPE dans leurs activités. C’est donc dans ce contexte professionnel et technologique que l’équipe technique de la société EURÊKA C.I a entrepris le développement d’une solution de management de l’innovation. Celle-ci se veut intelligente, intuitive et simple d’utilisation, pour le suivi collaboratif de l’activité de Recherche, développement et Innovation (RDI) des PME et TPE. Cette solution prendra la forme d’une application web en mode SaaS, avec pour mots clés : Simplicité d’utilisation - Ergonomie fonctionnelle - Interactivité avec l’utilisateur et - Approche intelligente de pilotage. A travers ce projet de développement numérique, le cabinet EURÊKA C.I veut contribuer à l’enrichissement de son offre de conseil en innovation. Ceci en apportant à ses clients (TPE et PME innovantes), un outil efficace et simple de gestion de leurs activités RDI. EURÊKA C.I

4

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Outre le gain en structuration de l’activité RDI, l’avantage pour une TPE ou une PME d’utiliser cet outil (baptisé RDI Manager) sera aussi lié au fait que l’approche de développement de celui-ci est orientée vers une vision de management stratégique et financier de la RDI. Un aspect non-négligeable dans une France prônant l’entreprenariat innovant. Ce rapport de stage présente globalement les travaux réalisés dans le cadre de ce projet de développement numérique dans le domaine du management de la RDI au sein des types PME et TPE. Le premier chapitre présente succinctement la société EURÊKA C.I, son activité et l’équipe dans laquelle le stage s’est déroulé . Il débouche sur une présentation détaillée du projet de stage et son positionnement technico-économique. Le deuxième chapitre introduit les spécifications fonctionnelles et techniques de la plateforme RDI Manager. Il se poursuit par la phase de conception, ainsi que la modélisation de la base de données associée. Le troisième et dernier chapitre se focalise sur le codage du front-end, du back-end, ainsi que des règles métier qui lient les différentes couches de la plateforme. Enfin, une conclusion résume l’ensemble du travail réalisé dans le cadre de ce stage, tout en mettant en évidence son apport dans le cadre du Master. Elle débouche sur des perspectives à donner au projet en phase avec l’objectif visé par la société EURÊKA C.I.

EURÊKA C.I

5

Strictement confidentiel

Chapitre 2 EURÊKA C.I et le projet RDI Manager Dans cette partie du chapitre, nous présentons succinctement le cabinet EURÊKA C.I qui a servi d’entreprise d’accueil pour ce stage. Ensuite, nous parlerons brièvement de son activité et des enjeux d’innovation des PME et TPE, qui ont quelque part conduit au lancement de ce projet.

2.1

Le cabinet EURÊKA C.I

EURÊKA C.I est un cabinet de conseil en innovation créé en septembre 2017. Il accompagne les entreprises de type TPE, PME et ETI dans le management stratégique et financier de leurs activités de recherche, développement et innovation. Il s’agit d’une approche globale du conseil en innovation qui s’appuie sur trois principaux axes de conseil : 1. la structuration de l’activité RDI de la société. 2. le Financement de la RDI. 3. le Management stratégique de l’innovation. Ceci afin de maximiser le potentiel de financement et d’innovation de la société. Pour réaliser cet accompagnement global, le cabinet s’appuie sur une équipe de consultants de formation doctorale, expérimentés et dynamiques. Il compte depuis peu trois bureaux en France : — EURÊKA Grand Paris, situé en Ile-de-France (Saint-Quentin En Yvelines) pour les clients basés au le Nord de la Loire. Il s’agit du bureau principal et celui dans lequel ce stage a été réalisé. — EURÊKA Grand EST, situé dans les Vosges (Saint-Dié Des Vosges) pour répondre aux besoins des clients des régions de l’est de la France (Alsace, Lorraine, FrancheComté). — EURÊKA Grand SUD, le tout dernière bureau lancé au cours de l’été 2020. Il regroupe pour l’instant les régions Provence Alpes Côte d’Azur et la Corse. A ce jour, ce jeune cabinet dynamique compte une dizaine de salariés quasiment tous de formation doctorale. Le tableau 2.1 ci-dessous présente la fiche administrative de la société. La figure 2.1 présente l’organigramme de la société ainsi que les 3 principaux bureaux opérationnels à ce jour. Le bureau du Grand SUD-OUEST (Occitanie et Nouvelle Aquitaine) 6

Université G. Eiffel

Rapport de Stage M2

est encore en projet, pendant que la région du Grand OUEST (Loire atlantique et Bretagne) est couverte par un cabinet partenaire [7]. Dénomination

EURÊKA C.I

Forme juridique

SAS, société par actions simplifiée

Année de création

2017

SIREN

832 231 526

SIRET

832 231 526 00027

Effectif

9 employés

Adresse

2 RUE Eugène Pottier 78190 SQY - Grand PARIS

Numéro de téléphone

(+33) 01 30 50 13 49

E-mail

[email protected] Table 2.1 – La fiche administrative EURÊKA C.I

Figure 2.1 – Organigramme de la société D’une manière générale, les collaborateurs du cabinet peuvent se regrouper autour de deux équipes : - une équipe Conseil orientée ingénierie et RDI et - une équipe Commerce orientée Marketing et RDI. Le stage a été réalisé au sein de l’équipe Conseil en collaboration avec un Ingénieur Innovation TIC, deux stagiaires en développement web (en formation continue) et un Manager innovation en chef.

2.1.1

Les principales missions conseil du cabinet

Les trois principales missions réalisées par le cabinet sont : - le conseil en management stratégique de l’innovation - le conseil en financement de l’innovation et - le conseil en EURÊKA C.I

7

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

politique d’innovation et de développement. Outre ces trois principales missions, le cabinet étoffe son offre conseil par l’accompagnement à la conduite de projet d’innovation, le conseil en gestion de la propriété intellectuelle et le conseil pour l’aide à l’export. Ceci est possible grâce à différents partenariats stratégiques, ainsi qu’à une activité d’ingénierie d’innovation permanente au sein de la société. La figure 2.2 ci-dessous illustre synthétiquement l’offre de conseil et les missions du cabinet. Les trois principaux axes de conseil du cabinet sont présentés plus bas [7].

Figure 2.2 – L’offre de conseil EURÊKA C.I [7]

Le management stratégique de l’innovation Dans ce volet de l’accompagnement EURÊKA, le cabinet accompagne les entreprises innovantes (TPE, PME et ETI) dans - la structuration de leur activité RDI - le renforcement de leurs équipes et - le développement de partenariats public-privé en R&D. L’idée ici est d’aider l’entreprise innovante à renforcer son potentiel d’innovation et de financement. Ceci passe par des actions concrètes telles que : - la mise en évidence des axes RDI porteurs de financements - l’analyse des besoins scientifiques, techniques - l’accompagnement au recrutement scientifique (notamment de jeunes docteurs) - l’aide au montage des partenariats public-privés en R&D et dans certains cas à - l’accompagnement technique dans la maîtrise d’oeuvre de projet R&D. Le financement de l’innovation Depuis près d’une dizaine d’année, la France a adopté une politique de soutien à la recherche et à l’innovation très ambitieuse. Celle-ci est en grande partie tournée vers les entreprises porteuses d’innovation, de croissance et d’emplois. Cette politique de soutien à l’innovation au sein des entreprises est également encouragée par l’Europe et se traduit par EURÊKA C.I

8

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

des aides fiscales à l’innovation, des subventions publiques, des avances remboursables de trésorerie, et même par des subventions d’entreprises du CAC40 auprès des start-up. Parmi ces dispositifs de financement [7, 4, 15], on peut citer par exemple : — Le Crédit d’Impôt Recherche (CIR), qui est un dispositif fiscal qui rembourse 30% des dépenses de recherche et développement expérimental des entreprises sur l’année civil. — Le Crédit d’Impôt Innovation (CII), qui est un dispositif fiscal complémentaire au crédit impôt recherche. Il rembourse 20% des dépenses liées aux activités d’innovation qui ne découlent pas directement d’une démarche de recherche et développement. Il est réservé au PME au sens de l’Europe 1 , et constitue avec le CIR le premier dispositif de financement de la RDI en France. — La Jeune Entreprise Innovante (JEI) est un dispositif d’aide fiscale au jeunes entreprises (moins de 8 ans) qui réalisent au moins 15% de leurs dépenses en R&D. Elle permet principalement à ces dernières de bénéficier d’allègements sur les charges patronales relatives aux salaires de leurs équipes RDI. — Les Aides et Subventions sont des dispositifs qui financent des projets (RDI dans notre cas) suivant des priorités de financement bien définies. Elles peuvent être municipales (comme celle de la ville de Paris auprès des Start-up), régionales, nationales ou européennes. A l’échelle régionale, on peut citer par exemple le dispositif PM-UP Covid-19, qui finance en ce moment les projets RDI liés à la lutte contre l’épidémie du Covid-19. A l’échelle nationale, on peut citer les aides et subvention de l’ADEME (Agence de la transition écologique) dont les priorités sont l’environnement, l’énergie et l’écologie. A l’échelle européenne, on a principalement les programmes-cadres de recherche de l’Union européenne. Il s’agit par exemple du programme Horizon 2020 qui s’achève cette année, et laissera la place à un nouveau programme cadre qui s’appuiera sur des priorités bien définies (en fonction des enjeux européens du moment).

La politique d’innovation et de développement Dans ce volet des missions conseil du cabinet, l’équipe, EURÊKA C.I s’appuie sur son expérience internationale, pour conseiller les institutions publiques des pays émergeants dans la mise en place d’environnements propices à l’émergence de clusters de recherche et innovation. Elle s’investit principalement dans les développements Nord-Sud en RDI, afin de faciliter les échanges universitaires et entrepreneuriaux (installation de sociétés innovantes en France par exemple).

2.1.2

Enjeux d’innovation au sein des PME

L’innovation est le résultat d’une démarche technique, technologique et stratégique qui conduit à la mise sur le marché d’un produit nouveau. Ce dernier peut se présenter sous forme d’un bien matériel (produit physique ) ou d’un bien immatériel (service, procédé, ... 1. Une PME au sens communautaire (au sens de l’Europe), est une entreprise qui possède moins de 250 salariés, et n’excède pas un chiffre d’affaires annuel de 50 millions d’euros ou un total de bilan annuel de 43 millions d’euros. Celle-ci est détenue majoritairement par des personnes physiques.

EURÊKA C.I

9

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

etc.) [16]. Au sein des PME et TPE, l’innovation est non seulement un enjeu de croissance, mais aussi un gage de survie. De nos jours [7], la quasi-totalité des entreprises (et en particulier les PME et TPE) s’investissent avec plus ou moins d’ambition dans une démarche d’innovation (R&D inclue). Cependant, investir en RDI, c’est aussi prendre des risques. Or pour augmenter les chances de réussite d’un projet, il est important de le gérer efficacement, afin d’éliminer étape par étape ses risques d’échec. En d’autres termes, il est important d’être bien structurer afin de mieux piloter son projet (ou son activité). Ceci est encore plus valable lorsqu’il s’agit d’un projet RDI. Ainsi, outre les questions financières liées à l’engagement des sociétés en RDI, les PME et TPE font face à un réel problème de structuration dans le management de leur activité RDI. Le principal souci ici réside sur le fait que les outils de structuration et de management (de projet ou d’activité) qui leurs sont proposés, sont assez contraignants d’usage. Ces derniers auraient plutôt tendance à impacter négativement leur efficacité opérationnelle plutôt que de leur apporter une meilleure visibilité dans la gestion de leur activité. D’autre part, en plus du fait que de nombreuses PME et TPE abordent souvent des problématiques RDI particulièrement complexes, les financeurs publics (de la RDI) leurs exigent en général un minimum de structuration. Ceci suppose une traçabilité dans le suivi du projet (actions, temps passé par les ingénieurs et techniciens, documents de synthèses, et autres). Ainsi, la question de l’investissement en RDI des PME et TPE devient une question non-triviale, tant sur le plan financier que sur le plan opérationnel. Suite à ce constat assez pertinent réalisé par l’équipe du cabinet, EURÊKA C.I a mis en évidence le besoin d’un outil simple d’utilisation, efficace, intelligent et non-contraignant, pour le management de l’innovation au sein des PME et TPE. Ceci dans une vision stratégique et financière de pilotage de leur activité. C’est donc dans cette optique que le cabinet a initié le développement de l’outil RDI Manager qui fait l’objet de ce stage.

2.2

Le Projet de Stage : RDI Manager

Ce stage porte principalement sur le développement de l’application RDI Manager. Il s’agit d’une plateforme numérique de management de l’innovation adaptée aux enjeux d’innovation des PME et TPE. Elle est basée sur une approche simple, intuitive, collaborative, interactive et efficace pour aider les PME et TPE dans le management stratégique et financier de leur activité de recherche et innovation. Via RDI Manager les parties prenantes (internes principalement) des entreprises innovantes pourront suivre, de manière collaborative et interactive l’ensemble des actions et faits marquants relatifs à l’activité RDI de la société. L’idée du développement de cette application se base sur un modèle épuré de gestion de projets RDI : * Un projet définit par son identité : - titre - acronyme - résumé - date début et date prévisionnel de fin - chef de projet - membres du projet avec différents rôles (observateur, participant actif et participant en chef), ... etc. ; * Des faits marquants du projet qui retracent de manière chronologique les actions et l’évolution du projet au cours du temps. Ceux-ci sont édités au cours de l’avanEURÊKA C.I

10

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

cement du projet par les participants actifs et participants en chef du projet et sont notifiés et visibles par tous les membres du projet ; * Un système de relance email et sms qui permet de rappeler aux participants du projet de renseigner les faits marquants du projet de manière périodique. Cette approche simple de gestion des projets de la société sera accompagnée par un module efficace et simple de suivi du temps des participants au projet. Celuici permettra d’enregistrer progressivement le temps RDI des collaborateurs passé sur les différents projets et le temps d’absence. Une notification sms et un email de relance seront envoyés tous les mois aux participants du projet pour qu’ils renseignent leurs données de temps RDI. En plus du module de suivi de temps des projets RDI, un module d’intelligence artificielle est associé à la plateforme. Celui-ci permet de donner une information sur la qualification RDI du projet. Il sera basé sur une approche intelligente d’analyse des données du projet (résumé, faits marquants et autres) pour qualifier celui-ci en projet de type RDI ou pas.L’idée ici est de permettre au chef de projet d’envisager une demande de financement publique de type CIR, CII ou Aides et Subvention, pour le projet. Ainsi, du point de vue de l’utilisateur de l’entreprise innovante (TPE et PME), les principales fonctionnalités de management du projet seront les suivantes : Créer, modifier et supprimer un projet

Visualiser la liste des projets

Créer, modifier et supprimer un participant

Visualiser un suivi projet

Saisir le temps RDI

Gérer les participants d’un projet

Saisir les jours d’absences

Ajouter un fichier à un projet

Un tableau de bord associé au front-end utilisateur donnera des informations générales sur la gestion de l’activité RDI de la société. Celui-ci sera composé de tableaux et de graphiques synthétiques. Le back-end de cette plateforme permettra de gérer la base de données, les sociétés, les licences et les utilisateurs administrateurs de la plateforme. Les principales fonctionnalités à développer ici sont les suivantes : Créer, modifier et supprimer une société

Visualiser la liste des sociétés

Créer, modifier et supprimer un utilisateur

Visualiser liste des utilisateurs

Comme on peut le constater, la plateforme RDI Manager a pour ambition d’apporter une approche épurée, simple et non contraignante de gestion de l’activité RDI pour les PME et TPE. La section suivante présente une comparaison succincte de RDI Manager vis-à-vis de la concurrence.

2.2.1

État du marché

En termes d’outils de gestion de projets, on peut trouver près d’une vingtaine d’applications numériques sur le marché. Celles-ci peuvent être classées en deux groupes vis-à-vis de RDI Manager. EURÊKA C.I

11

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

En effet, on a d’une part les outils généralistes de gestion de projets ; et d’autre part des outils thématiques de gestion des projets (voir figure 2.3. Cependant, on peut constater que la quasi-totalité de ces outils sont parfois assez complexes, car ils sont constitués d’un nombre trop important de fonctionnalités. Ces outils numériques ne sont en fait valorisés que lorsque toute ces fonctionnalités sont pleinement utilisées. Ce qui les rend particulièrement contraignantes pour l’utilisateur qui est fortement sollicité par l’outil numérique pour gérer son projet. Parmi ces applications, on peut citer MS PROJECT [14] ou REDMINE [20] dont les fonctionnalités vont de la gestion collaborative des projets, jusqu’au forum de discussion par projet, en passant par des analyses de type diagramme de Gantt et bien d’autres. Il s’agit là de quelques exemples de fonctionnalités qui sont loin d’être pertinentes à l’échelle des PME et TPE. En effet, ce type de fonctionnalités n’auront pour effet que de complexifier l’utilisation de l’outil de gestion de projet pour les collaborateurs de la PME/TPE. Par ailleurs, on peut aussi trouver sur le marché des applications de gestion de projets qui essayent de se focaliser exclusivement sur des besoins liés au management de la recherche et innovation. Celles-ci apportent des fonctionnalités précises à l’entreprise pour la gestion de son activité RDI. Le problème avec la plupart de ces applications est qu’elles ont aussi tendance à vouloir tout gérer sur la plateforme : de la gestion collaborative multi-projet, aux analyses financières tel que le calcul du CIR, en passant par les analyses de type Gantt. C’est le cas par exemple du logiciel R&D Tracker [12] développé par un concurrent du cabinet EURÊKA C.I. Ce logiciel ambitionne de tout gérer dans l’activité RDI d’une société via la plateforme. Il a fini en échec commercial car personne ne veut l’utiliser. Ceci du fait de sa complexité : Les PME et TPE ont besoin de simplicité et d’efficacité dans leur approche de management, puisqu’elles n’ont pas beaucoup de ressources. En fait, les principaux acteurs de RDI (techniciens, ingénieurs, managers, chef de projets) n’expriment en général pas beaucoup de passion à s’occuper des tâches de gestion et d’administration. De même leur services administration n’ont pas toujours suffisamment de ressources à consacrer à une gestion des projets particulièrement complexe. Tous ont en fait besoin de simplicité et d’efficacité dans la gestion de leurs projets/activités. C’est ainsi que dans la division recherche et développement du Groupe Saint-Gobain (SGR), l’application R2D2 a été développée pour gérer l’activité RDI de cette filiale à taille de PME [7]. Celle-ci pilote son activité (qui se résume à la RDI) en collaboration avec les unités de production du groupe via l’outil R2D2. Cette plateforme numérique se base sur une approche simple et efficace de suivi collaboratif des projets par ses participants en interne SGR, le top management de SGR et les parties prenantes des filiales industrielles du groupe. Bien que cette dernière application n’ait pas de module de suivi de temps, de relance mobile des collaborateurs, ni de qualification RDI des projets, il s’agit là d’une solution assez adapter au TPE et PME. RDI Manager devrait s’inscrire dans le prolongement de celle-ci en termes d’innovation et de simplicité. Le tableau en figure 2.3 présente de manière fonctionnelle les principaux outils existants sur le marché, ainsi que leurs différentes fonctionnalités.

EURÊKA C.I

12

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Figure 2.3 – Analyse des produits concurrents sur le marché Dans ce marché a priori saturé d’outils numériques de gestion de projet, RDI Manager veut se positionner comme l’outil le plus simple, le plus efficace et le plus intelligent pour le suivi et la gestion de l’activité RDI des PME et TPE. La figure 2.4 illustre ce positionnement par rapport aux outils les plus pertinents du marché.

EURÊKA C.I

13

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Figure 2.4 – Positionnement de RDI Manager vis-à-vis de la concurrence En effet, lorsqu’on compare RDI Manager aux autres produits du marché, on constate que celui-ci se distingue par sa simplicité d’utilisation et ses fonctionnalités adaptés aux exigences des PME et TPE. Le module IA ajouter au logiciel facilite l’analyse stratégique de l’activité RDI de la société via le tableau de bord de l’application. L’analyse SWOT (figure 2.5) réalisée dans le cadre de ce projet, pointe l’approche simplifié de conception de cette application comme à la fois un atout et un handicap (du point de vue générale). Cependant, lorsqu’on se focalise sur le marché cible des PME et TPE innovantes, ce choix de conception (simplicité de l’application) se défend parfaitement. En effet, l’enchainement logique et efficace du menu de navigation, le suivi du temps, les notifications mobile et mail, ainsi que le module d’IA sont les principaux atouts qui font la force de RDI Manager.

Figure 2.5 – Analyse SWOT de la plateforme RDI Manager EURÊKA C.I

14

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

En termes de pénétration dans son marché cible (PME et TPE), RDI Manager pourra profiter de la clientèle de base de la société EURÊKA C.I pour lancer son développement commercial. Cependant, elle devra affronter des obstacles non-négligeables que représentent les autres acteurs du marché qui se focalisent aussi sur le management de la RDI. Ceci étant, RDI Manager pourra s’appuyer sur ses atouts technologiques tels que le module d’IA et les relances mobiles pour prendre un avantage stratégique par rapport à ses concurrents directs.

2.2.2

État de l’art

L’utilisation du web et des applications qu’il héberge est aujourd’hui une chose courante. Nous utilisons presque tous internet pour différents buts (rechercher des informations, réaliser des achats, jouer, écouter de la musique ou regarder une vidéo). Cet univers numérique qui enrichi nos vies au quotidien est en grande partie basé sur des applications dites web. Une application web est un programme de type client-serveur qui s’exécute sur le web et rend un service. D’une manière plus explicite, une application web est une collection de documents HTML/XML, de composants web et d’autres ressources, dans une structure de répertoires ou sous forme d’une archive appelée fichier WAR (Web Archive). Celle-ci réside sur un serveur central et fournit des services à une variété de clients ][17, 13]. La nature et la complexité de ces applications peuvent être très différentes. Dans le cas du projet RDI Manager, on a affaire à une application de type plateforme numérique, qui combine page web (HTML), base de données et un modèle d’intelligence artificielle. - Développement d’applications web Pour développer une application web, deux approches standard de programmation sont le plus souvent utilisées. Il s’agit des langages open source Java et PHP. Ceux-ci représentent presqu’à parts égales 66% des utilisations de langage de programmation d’applications web au monde [21]. Java est réputé pour son approche très pédagogique de programmation. Il oblige à coder de manière propre et impose plus de rigueur de la part du développeur. C’est un langage au "typage" fort et statique, puisqu’il aide à définir explicitement le type de chaque variable. Ceci pousse le développeur à avoir une connaissance plus précise de son code. En Java, les développeurs utilisent en général les Frameworks JEE ou SPRING pour structurer et accélérer le développement. En termes de performances, Java n’excelle pas particulièrement par rapport aux autres langages tels que C, C++ ou PHP. Ceci du fait qu’il s’agit à la base d’un langage précompilé et interprété au sein d’une JVM [17]. En ce qui concerne l’hébergement et la gestion serveurs, JAVA JEE nécessite un serveur d’application ou a minima un conteneur de servlet de type Tomcat pour déployer son application. L’utilisation de ce type de serveur exclue immédiatement les offres de type hébergement web, qui offrent simplement un répertoire et un serveur Apache pour publier son site web. Sans conteneur ou serveur d’application, le déploiement n’est pas possible. Il est nécessaire ici de travailler avec des professionnels pour l’hébergement. PHP est un langage de scripts généraliste, spécialement conçu pour le développement d’applications web. Il s’intègre facilement au HTML, car ses pages contiennent déjà des fragments HTML. Ceci évite d’utiliser plusieurs commandes pour afficher les pages HTML EURÊKA C.I

15

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

(comme c’est le cas avec Java). Les développements PHP sont généralement réalisés à l’aide des Frameworks ZEND ou Symfony. Symfony est le Framework de référence sous PHP [5]. Il permet entre autre de créer des applications web, de manière rapide et structurée. Ceci permet aux développeurs de gagner du temps dans le développement des tâches de fond, pour se concentrer sur les fonctionnalités essentielles de l’application. L’un des points qui distingue PHP des langages de script comme le Javascript, est que le code PHP s’exécute sur le serveur, générant ainsi le HTML, qui sera ensuite envoyé au client. Le client ne reçoit que le résultat du script, sans aucun moyen d’avoir accès au code qui a produit ce résultat. Ceci donne la possibilité à PHP d’être directement déployé sur un serveur de type web (sans serveur d’application). Ceci permet ainsi d’étendre l’offre d’hébergement de l’application vers des hébergement sans conteneur ou serveur d’application comme avec Java. L’un des grands avantages de PHP est qu’il est extrêmement simple de prise en main pour les néophytes tout en offrant des fonctionnalités avancées pour les experts. Cependant, en termes de sécurité des données, toute la communauté des développeurs s’accorde à dire qu’il est plus difficile de se prémunir des attaques avec PHP, car le langage ne force pas à se sécuriser. Ce qui est tout le contraire avec Java JEE qui valide à chaque étape les données de telle sorte qu’il est presque impossible de faire des attaques de types SQL injection par exemple. - Base de Données et Système de Gestion de base de données Une base de données est un ensemble structuré de données apparentées, qui modélisent un univers réel. Elle permet d’enregistrer des faits, des opérations au sein d’un organisme (administration, banque, université, hôpital, ...) ou d’un système. On parle alors d’un Système de Gestion de Base de Données (SGBD : Data Base Management System). Un système de gestion de base de données est un système qui permet de gérer une base de données partagée entre plusieurs utilisateurs simultanément. C’est par exemple le cas d’utilisation de la plateforme RDI Manager que nous souhaitons développer. Il existe plusieurs modèles de base de données : — le modèle hiérarchique : les données sont classées hiérarchiquement, selon une arborescence descendante. Ce modèle utilise des pointeurs entre les différents enregistrements. Il s’agit du premier modèle de SGBD ; — le modèle réseau : Comme le modèle hiérarchique, ce modèle utilise des pointeurs vers des enregistrements. Toutefois la structure n’est plus forcément arborescente dans le sens descendant ; — le modèle relationnel (Système de gestion de bases de données relationnelles) : les données sont enregistrées dans des tableaux à deux dimensions (lignes et colonnes). La manipulation de ces données se fait selon la théorie mathématique des relations, théorie ensembliste ; — le modèle objet, dans lequel les données sont stockées sous forme d’objets, c’est-à-dire de structures appelées classes présentant des données ; — le modèle XML, ce modèle est bâti sur un référentiel de contenu décrit et structuré en XML via des DTD ou Schémas. Le langage de requête est du XML : Xquery, XPath, eXist, Apache Xindice. La figure 2.6 illustre quelques-uns de ces modèles de base de données. En effet, outre EURÊKA C.I

16

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

les bases de données dites spécialisées (documentaires ou géographiques) où les schémas traditionnels ne conviennent pas ; la majorité des bases de données développées de nos jours sont faites suivant le modèle relationnel.

Figure 2.6 – Principaux modèles de base de données, inspiré de [10, 3] Le modèle relationnel est basé sur une modélisation des relations qui définissent le monde réel. Celui-ci est constitué de domaines qui représentent l’ensemble des valeurs possibles dans lesquelles sont puisées les données. Deux ensembles peuvent avoir les mêmes valeurs bien que sémantiquement distinctes. Les relations représentent des sous-ensembles du produit cartésien de plusieurs domaines. On peut considérer une relation comme un PRÉDICAT à n variables. Les éléments d’une relation sont alors appelés des n-uplets de valeurs (ou tuple en anglais). Il s’agit là de faits du monde réel. Suivant cette conception, chaque composante d’une relation est alors appelée un attribut, et le nom donné à un attribut doit être porteur de sens. Il est en général différent du nom du domaine, car plusieurs attributs peuvent avoir le même domaine. Suivant cette modélisation, le schéma d’une relation est défini par le nom de la relation et la liste de ses attributs. Le schéma d’une base de données quant à lui, est défini par l’ensemble des schémas des relations qui la composent. Pour décrire et manipuler les bases de données relationnelles, on utilise les langages assertionnels. Ceux-ci permettent de spécifier les ensembles de données à sélectionner ou à mettre à jour à partir de propriétés des valeurs (qualification). Ceci sans dire comment retrouver les données. Deux classes de langages correspondant à la manière de considérer une relation : comme un ensemble, ou comme un prédicat. Les langages ensemblistes sont basés sur une approche d’algèbre relationnelle ; pendant que les langages prédicatifs sont basés sur le calcul de prédicats. Parmi les langages ensemblistes, on a principalement le langage SQL (Structured Query Language). Celui-ci est en quelque sorte un paraphrasage du langage algébrique (référence à tous les langages relationnels). Introduit par IBM et basé sur des standards d’accès aux données et une normalisation ISO des schémas, SQL est devenu le langage standard pour décrire et manipuler les bases de données relationnelles (BDR). C’est un langage situé à l’interface logiciel-logiciel entre les applications et les systèmes de gestion de bases de données relationnelles tels que MySQL AB, ORACLE, DB2 INGRES, SYBASE et INFORMIX. Dans les approches courantes de développement de modèles de gestion de bases de donEURÊKA C.I

17

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

nées relationnelles, les développeurs utilisent des logiciels tels que MySQL, Oracle Database, PostgreSQL et Microsoft SQL Server. Ces derniers permettent une approche simplifiée de modélisation de la base de données. Le développement de la base de données se résume alors à la définition des tables, de leurs attributs, ainsi que des liens relationnels entre-elles. Ainsi, dans le développement d’une plateforme telle que RDI Manager, à la suite du développement de l’interface de l’application web (Couche de présentation), et de la base de données (Couche d’accès aux données) ; le développement de la couche métier (ou Couche de traitement), devrait permettre de faire le lien entre l’interface utilisateur et la BDD. Celleci correspond à la partie fonctionnelle de l’application qui implémente la logique métier. Elle décrit les opérations que l’application opère sur les données en fonction des requêtes des utilisateurs, effectuées au travers de la couche de présentation. Les différentes règles de gestion et de contrôle du système sont également mises en oeuvre dans cette couche. Dans le cas précis de RDI Manager, le module d’intelligence artificielle par exemple devrait être intégré à la plateforme via cette couche. - Intelligence artificielle L’intelligence artificielle est de loin le volet le plus exotique dans le développement de la plateforme RDI Manager. En effet, outre le fait d’être une thématique d’actualité de nos jours ; l’intelligence artificielle (IA) est l’ensemble des théories et des techniques mises en oeuvre en vue de réaliser des machines capables de simuler l’intelligence [6]. On distingue en général l’intelligence artificielle forte et l’intelligence artificielle faible. Le concept d’intelligence artificielle forte fait référence à une machine capable non seulement de produire un comportement intelligent, notamment de modéliser des idées abstraites ; mais aussi d’éprouver une impression d’une réelle conscience, de vrais sentiments et une compréhension de ses propres raisonnements [2]. Celle-ci se distingue de l’IA généralisée, qui désigne tout système capable d’apprendre et d’effectuer n’importe quelle tâche qu’un humain serait capable de faire. La notion d’intelligence artificielle faible constitue une approche pragmatique d’ingénieur. L’idée ici est de chercher à construire des systèmes de plus en plus autonomes, afin de réduire le coût de leur supervision. Ceci passe par exemple par le développement d’algorithmes capables de résoudre des problèmes d’une certaine classe. Dans cette approche de l’IA, la machine simule l’intelligence, elle semble agir comme si elle était intelligente. C’est vers ce type de modèle d’IA que devrait s’orienter le modèle envisagé sous la plateforme RDI Manager. En effet, le terme d’intelligence artificielle désigne aussi des systèmes capables de résoudre uniquement un type de problème pour un jeu de données prédéfini [22]. Ce type d’approche d’intelligence artificielle, nommée narrow AI (intelligence artificielle étroite) est conçu spécifiquement sur une tâche bien définie. Elle ne prévoit aucun développement particulier pour la généraliser comme le ferait une IA forte. Cependant, elle n’en perd pas moins son utilité, et reste très utilisée dans l’industrie. Parmi les champs de développement de l’intelligence artificielle, on peut citer l’analyse sémantique (deep learning) et l’apprentissage automatique (machine learning). Dans le premier cas, on se base sur une approche mathématique et statistique pour demander à la machine de prendre une décision après avoir analysé un certain nombre de données (en général grand). Il s’agit là d’une approche de type narrow AI. Dans le second cas, l’approches mathématiques et statistiques permet de donner à l’orEURÊKA C.I

18

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

dinateur la capacité d’apprendre à partir de données. Ceci suppose d’améliorer les performances de l’ordinateur à résoudre des tâches sans être explicitement programmé pour chacune d’elle. Il s’agit là d’une approche bien plus complexe d’IA (intelligence artificielle généralisée), bien qu’elle ne puisse pas encore être qualifiée d’IA forte. Ainsi dans le cas du développement du modèle d’IA de la plateforme RDI Manager, on s’orienterait plus vers une IA faible. Et l’enjeu de développement ici portera principalement sur le modèle d’analyse sémantique des données du projet pour qualifier celui-ci de projet RDI valorisable ou pas. C’est donc dans ce contexte économique et technologique que nous nous sommes lancés dans le développement de cette application de Management de l’innovation.

EURÊKA C.I

19

Strictement confidentiel

Chapitre 3 Conception technique de la plateforme Dans ce chapitre nous présentons la conception architecturale globale de la plateforme RDI Manager. Il est question ici d’entrer dans le détail des spécifications techniques et fonctionnelles de la plateforme, de modéliser les principaux scénarios d’utilisation, ainsi que de concevoir l’architecture du système de gestion de la base de données.

3.1

Spécifications de l’application

Cette section présente de manière détaillée les spécifications de développement de l’application. Elle traduit de manière opérationnelle le cahier des charges défini par le donneur d’ordre (le manager EURÊKA C.I). Ce cahier de spécifications permet de valider la bonne compréhension de la demande EURÊKA C.I, ainsi que de présenter les solutions apportées en réponse à celle-ci. L’idée ici est d’avoir une vision complète du projet pour l’équipe technique du projet. En général, les spécifications projet sont divisés en 2 parties : les spécifications techniques et les spécifications fonctionnelles.

3.1.1

Spécifications fonctionnelles

Pour spécifier les fonctionnalités de notre application, il a été nécessaire de faire une étude synthétique de son périmètre fonctionnel. L’idée ici était de mettre en évidences les principaux acteurs de la plateforme puis de décrire leurs droits et attributions. Ceci nous permettra de lister les principales fonctionnalités nécessaires pour répondre aux besoins de développement. Pour ce faire, nous avons considéré deux groupes d’acteurs : - Les acteurs front-office qui sont les principaux utilisateurs à qui est destiné l’application. Il s’agit des sociétés innovantes et leur personnel technique. Dans cette partie nous détaillons les fonctionnalités et leurs périmètres d’usage. - Les acteurs back-office qui sont constitués par l’équipe administrateurs en interne EURÊKA C.I. - Back Office Le Back Office est en effet dédié à l’administration de l’application par EURÊKA C.I. Ceci consiste principalement à la gestion des comptes des sociétés par les membres d’EURÊKA C.I (Administrateur général et référents EURÊKA des sociétés). Le tableau en figure 4.4 ci-dessous présente les différents profils back-office de la plateforme, ainsi que leurs descriptions fonctionnelles. 20

Université G. Eiffel

Rapport de Stage M2

Figure 3.1 – Tableau des acteurs back-office et leurs descriptions fonctionnelles - Front Office Le Front Office quant-à-lui est dédié aux utilisateurs des sociétés innovantes. Cet interface utilisateur permet de suivre les projets, ainsi que de réaliser différentes actions parmi lesquelles la gestion des participants, le suivi des faits marquants et le suivi du temps passé par projet. Le tableau en figure 3.2 ci-dessous présente les acteurs front-office et leurs descriptions fonctionnelles.

Figure 3.2 – Tableau des acteurs front-office et leurs descriptions fonctionnelles A partir de cette description fonctionnelle nous avons réalisé une étude des scénarios d’utilisation de la plateforme en se basant sur le cahier des charges du projet. Ceci nous a permis de définir les fonctionnalités nécessaires pour l’application, tout en les associant aux droits d’utilisation et d’accès des différents acteurs. Le tableau en figure 3.3 ci-dessous illustre cette mise en évidence des fonctionnalités de l’application. Ces dernières sont regroupées autour de : — La création, la visualisation et la modification d’une société pour le back-office ; — La création, la visualisation et la modification d’un projet pour le front-office. Outre ces deux blocs de fonctionnalités, les fonctionnalités d’ajout et de gestion des utilisateurs seront utiles tant au front-office qu’au back-office. A ceci, il faudra ajouter des fonctionnalités liées au suivi et à l’enregistrement du temps passé sur les différents projets. Ce dernier groupe de fonctionnalités n’est utile que pour les utilisateurs front-office. Dans une vision globale du projet RDI Manager, il faudra aussi parler du bloc de fonctionnalités liées au module de simulation CIR et CII qui ne concerne que les utilisateurs back-office. Cependant, le périmètre de notre stage n’inclut pas ce module. Ainsi, à partir du tableau en figure 3.3, nous avons regroupé les différentes fonctionnalités de l’application suivant des modules qui définissent les blocs de fonctionnalités. Ceci est présenté en figure 3.4. EURÊKA C.I

21

Strictement confidentiel

22 Figure 3.3 – Rôles, attributions et droits des acteurs-utilisateurs Front & Back office

23 Figure 3.4 – Présentation modulaire des fonctionnalités RDI Manager

Université G. Eiffel

3.1.2

Rapport de Stage M2

Spécifications techniques

Les spécifications techniques d’un cahier des charges sont une documentation des méthodes, procédés, et technologies sélectionnées pour la réalisation d’un projet technique. Dans le cas du développement de la plateforme RDI Manager, nous avons choisi des technologies éprouvées dans le domaine du développement d’applications web. Ces technologies sont disponibles en open source et soutenues par une grande communauté de développeurs (plusieurs millions d’utilisateurs). Ceci permet de profiter de la synergie de la communauté pour mieux avancer dans ses développements. Ainsi, en termes de langages de programmation, nous avons utilisé : — PHP sous sa version 7.4.6 pour de développement des interfaces utilisateurs ; — HTML sous sa version 5 pour le développement des pages web ; — CSS sous sa version 3 pour la mise en forme des pages web développées sous HTML ; — JavaScript a servi pour ouvrir des pop-up (les petites fenêtres qui s’ouvrent de manière intempestive),faire défiler un texte, et insérer un menu dynamique (qui se développe au passage de la souris) ; — Un moteur de templates, permet sous Symfony la présentation des données du traitement, la personnalisation de page web, de rendre les pages web plus lisibles, plus claires. — MySQL sous sa version 10.12 a servi au développement de la base de données. Au niveau de l’approche de codage, nous avons utilisé une structuration de code basée sur des frameworks standard dans le domaine. Il s’agit de standards et bonnes pratiques de codage mise à disposition et largement utilisé par la communauté des développeurs. Parmi ces frameworks, nous pouvons citer : — Symfony 4.4 pour le développement PHP Nous avons choisi la version 4.4 et non la dernière version (5.1) car celle-ci est une version LTS (Long Time Support) qui sera maintenue jusqu’à 2022. Elle est assez éprouvée et dispose de nombreux tutoriels et contributions d’utilisation au sein de la communauté des développeurs. Ce qui est tout le contraire de la version 5.1 qui est assez récente. De plus , en terme de fonctions et sous-programmes, les deux versions sont équivalentes au regard de nos besoins de développements. — Bootstrap pour la mise en forme du CSS Nous avons utilisé ce framework CSS et HTML pour optimiser la la création du design (graphisme, animation et interactions avec la page dans le navigateur, etc.) de la plateforme. Il permet en d’autres terme de gérer l’adaptation de l’interface utilisateur avec la taille de l’écran utilisateur (comportement responsive sur smartphone, tablette et ordinateur). Le fait que la Plateforme RDI Manager soit responsive est un point crucial du développment car les utilisateurs sont supposés recevoir certaines notifications sur leurs smartphones et réaliser certaines actions de manière simple et spontanée via leurs smartphones. C’est le cas par exemple de la mise à jour des feuilles de temps ou même de l’enregistrement des faits marquants. — Serveur de Base de données : MySql (version mariadb-10.4.11) Le type de base de donnée utilisé avec ce Framework SQL est InnoDB. Ce type de base de données permet au moteur MySQL de gérer les relations entre les tables contrairement au type MyIsam. En effet, bien que ce dernier soit plus rapide dans la recherche de données, il ne prend pas en charge la gestion des relations entre les tables. Compte tenu du faible volume EURÊKA C.I

24

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

de données à gérer par l’application, nous avons privilégié le type InnoDB qui prendra en charge les relations entre les tables tout en faisant preuve d’une bonne performance dans notre cas. — IDE utilisés pour le développement Visual Studio Code c’est un environnement de développement qui possède toutes les fonctionnalités d’un éditeur de code ainsi que la possibilité de compiler, tester, lancer, publier et sauvegarder le code dans un espace de stockage. Ces différentes technologies sont également choisies en tenant compte du fait que l’application RDI Manager sera distribuée en mode SaaS (software as a service). En effet, elles sont supportés par la majorité des hébergeurs web et pourront se déployer facilement sur des serveurs privés ou commerciaux.

3.2

Modélisation des scénarios nominaux

Dans la continuité des spécifications techniques et fonctionnelle du projet, nous avons modélisé les scénarios nominaux d’utilisation de la plateforme. Ceci a été réalisé à l’aide du langage UML (Unified Modeling Language). Il s’agit d’un langage formel de modélisation orientée objet. L’avantage d’utiliser cette approche de modélisation est qu’il permet de faciliter la représentation et la compréhension du développement par visualisation objet de la solution proposée. Ainsi, suivant cette approche, nous avons modélisé les différents cas d’utilisation front-office et back-office ; ainsi que les séquences d’interactions entre les différents objets de notre application.

3.2.1

Diagrammes de cas d’utilisation

Les diagrammes des cas d’utilisation présentent la vision globale du comportement fonctionnel de l’application. Il permet de détailler graphiquement les fonctionnalités ou cas d’utilisation décrits dans le cahier des charges. Un cas d’utilisation représente une unité discrète d’interaction entre l’utilisateur et le système. Dans un diagramme de cas d’utilisation, les utilisateurs sont appelés acteurs. Leurs différentes actions sont modélisées par des cas d’utilisations dans un diagramme dit de cas d’utilisation. Ainsi, dans le back-office et le front-office, l’analyse des cas d’utilisation réalisés abouti à ceci : — Back-office En back-office les trois groupes d’acteurs à prendre en compte dans la modélisation des cas d’utilisations sont : les Observateurs, les Référents société back-office et l’Administrateur. La modélisation des relations de généralisation entre les différents acteurs ici est réalisée en tenant compte des droits et attributs de ceux-ci. Suivant cette modélisation, le Référent société back-office hérite des cas d’utilisations associés à l’Observateur, pendant que l’Administrateur hérite des cas d’utilisations associés au Référent société back-office. Par implication, l’Administrateur hérite donc des cas d’utilisations de l’Observateur et ceux du Référent société back-office. Les différents cas d’utilisations étant relatifs aux rôles des acteurs (à leurs droits et leurs attributions) ; chaque cas d’utilisation ne s’exécute qu’après authentification et vérification du rôle utilisateur. Dans les scénarios illustrés en figure 3.5 ci-dessous, on peut remarquer que l’Observateur ne peut que - visualiser le récapitulatif d’informations - changer le mot de passe et - activer son compte. Tandis que le Référent société back-office peut en plus EURÊKA C.I

25

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

ajouter, modifier, supprimer un utilisateur de ses sociétés, et - visualiser la liste des utilisateurs de la plateforme. L’Administrateur quant-à lui peut réaliser les mêmes opérations (que Reférent société back-office) sur toutes les sociétés de la plateforme.

Figure 3.5 – Scénarios de gestion des utilisateurs Dans le scénario illustré en figure 3.6 ; après authentification un Observateur ne peut qu’afficher la liste de ses sociétés, pendant que le Référent société back-office peut créer une société, la modifier, la supprimer, supprimer des licences de ses sociétés, ainsi qu’afficher la liste des sociétés. L’Administrateur quant-à-lui, peut réaliser les mêmes opérations sur toutes les sociétés.

Figure 3.6 – Scénarios de gestion des sociétés — Front-office Le front office compte quatre acteurs pour la modélisation des scénarios : le Référent société front-office (qui est l’administrateur interne de la plateforme au sein de la société), le Chef de projet, le Participant projet et l’Observateur projet. Dans le premier cas d’utilisation (voir figure 3.7 ), après authentification, un Observateur peut visualiser ses projets, visualiser le détail de chacun de ses projets et exporter les données de ses projets (faits marquants et EURÊKA C.I

26

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

autres). Pendant qu’un Participant peut en plus saisir des faits marquants sur chacun de ses projets. Le Chef de projet hérite des cas d’utilisations du Participant et peut en plus créer des projets, visualiser, modifier et supprimer ses projets. Le Référent société front-office hérite des cas d’utilisations du chef de projet et peut réaliser ces opérations sur tous les projets de la société.

Figure 3.7 – Les scénarios de gestion des projets Dans le scénario lié au suivi du temps qui est illustré en figure 3.8 , on peut noter que l’Observateur n’est pas concerné par la saisie du temps par projet. Ceci est tout à fait en phase avec son rôle d’observateur, car il ne participe pas de manière active au projet. Cependant, le Référent société front-office, du fait de son rôle d’administrateur de l’application en interne dans la société, peut tout faire, y compris modifier les saisies des participants des projets au sens propre.

Figure 3.8 – Scénarios de suivi des temps

EURÊKA C.I

27

Strictement confidentiel

Université G. Eiffel

3.2.2

Rapport de Stage M2

Diagrammes de séquences

Les diagrammes de séquences représentent graphiquement les interactions entre les acteurs et le système selon un ordre chronologique dans la formulation UML. Ils permettent de montrer les interactions entre les objets, acteurs et le système dans les scénarios de diagrammes de cas d’utilisation. Suivant ce type de diagramme, l’objet est représenté par un rectangle dans lequel figure son nom, pendant que la ligne de vie indique les périodes d’activité de l’objet. Il s’agit en fait des moments où l’objet exécute une de ces méthodes. Lorsque l’objet est détruit, la ligne de vie s’achève par une croix. La communication entre les acteurs et les objets se fait par des messages. Dans le cas de notre projet, il a été question d’étudier l’ordre chronologique des interactions entre les utilisateurs, le système et la base de données. Ceci en back et front office. Dans le cas du back-office, nous avons modélisé les séquences de connexion des différents acteurs, ainsi que les messages échangés entre les objets (acteurs back-office), le système et la base de données. La figure 3.9 ci-dessous illustre un exemple de modélisation de la séquence de connexion d’un observateur. Lorsque ce dernier renseigne ses informations de connexion au système, un message est envoyé à la base de données où une recherche est réalisée suivant un algorithme automatique. Si l’utilisateur existe, la base de données renvoie un message qui permet l’authentification, l’affichage des données et l’activation des droits relatifs à l’utilisateur. Dans le cas de l’Observateur, seuls des droits de visualisation de la liste des utilisateurs et d’un certain nombre de société sont renvoyés. Si l’utilisateur n’existe pas dans la base de données, le message renvoyé est un message d’authentification non valide. Il en est de même pour les autres utilisateurs.

Figure 3.9 – Illustration de la séquence de connexion d’un Observateur Dans le cas d’interaction de modification des informations d’une société par exemple, le diagramme en figure 3.10 ci-dessous illustre la séquence de modification. Comme on peut EURÊKA C.I

28

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

le voir, l’utilisateur (Administrateur ou Référent société back-office), sollicite le système en envoyant un message de demande de modification. La demande est transmise à la base de données qui fait sa vérification et transmet les informations de modification des données au système. Celui-ci charge le formulaire de modification des données de la société. L’utilisateur peut alors entrer ses modifications, les valider ou annuler sa manoeuvre. Dans le cas où l’utilisateur valide ses modifications, un message de mise à jour des données est envoyé à la base de données.

Figure 3.10 – Illustration d’une séquence de modification des informations société On modélise de la même manière l’ensemble des séquences d’interactions du front-office, afin de valider les scénarios des cas d’utilisation. les diagrammes en figures 3.11 et 3.12 illustrent d’une part la séquence de l’activation de compte utilisateurs et d’autre part la séquence de visualisation des faits marquants.

EURÊKA C.I

29

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Figure 3.11 – Illustration d’une séquence d’activation de compte utilisateur front-office

Figure 3.12 – Illustration d’une séquence de visualisation de faits marquants d’un projet Ainsi, suite à la validation des ces différentes étapes de conception technique de la plateforme, nous avons initié la phase de modélisation de l’architecture de la plateforme. Cette partie des travaux est présentée dans la section ci-dessous.

3.3

Conception architecturale de la BDD

La base de données constitue le coeur de notre plateforme. Sa modélisation est l’une des tâches les plus complexes du processus de développement de notre système d’information. Celle-ci régit en effet, la collecte, le stockage, le traitement et l’utilisation des données. La conception de la base de données suit une démarche en trois étapes et fait appel à une approche de modélisation qui se base sur des tables. Les trois étapes de cette démarche de modélisation de la base de données ont été mises en oeuvre de la sorte : EURÊKA C.I

30

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

— Une première approche conceptuelle. Celle-ci représente le contenu de la base de données en termes conceptuels, indépendamment de toute considération informatique. Dans notre cas, celle-ci s’est inscrite dans la continuité de la modélisation des scénarios nominaux d’utilisation. En effet, l’analyse des scénarios permet de mettre en évidences les différents objets de la plateforme (de la base de données) ainsi que leurs attributions. En d’autres termes, elle met en évidence les informations de la base de données. — La seconde approche est celle de la modélisation de logique relationnelle. Elle résulte de la traduction du schéma conceptuel en un schéma propre de type de base de données. Cette étape de modélisation a été réalisée à partir du langage MySql. Il s’agit du langage de développement de base de données relationnelle le plus utilisé lorsqu’il s’agit de développer une de base de données relationnelle. Il est de plus supporté par une de nombreux langages de développement d’application web parmi lesquels PHP. — Le troisième niveau de développement de la base de données est celui de la modélisation de l’organisation et de l’accès aux données de la base. Celle-ci est codée via la couche d’accès aux données de la plateforme. Dans notre cas, ce développement du système de gestion de base de données est réalisé sous Symfony ; le framework PHP utilisé. En effet, nous avons utilisé MySql Workbench 8.0 pour la conception architecturale de la base de données. L’avantage de cette version est qu’elle fournit des outils efficaces de modélisation de données et d’administration (configuration du serveur, administration des utilisateurs et autres). Ceci nous a donc permis de concevoir un modèle logique de données qui consiste en une description de la structure de données utilisée sans faire référence à du codage au sens propre du terme. Il a été en effet question ici de définir les éléments de modélisation de la base ainsi que leurs propriétés et relations (les tables, leurs attributs, les types des attributs, les types de relations entre les tables, ainsi que les clés primaires et clés étrangères des tables). — Gestion des utilisateurs Suivant cette approche, la gestion des utilisateurs est alors modélisée par la création d’une table Utilisateurs qui contiendra les informations des différents utilisateurs frontoffice et back-office. Afin de distinguer les profils des utilisateurs, nous avons défini une table Profil qui attribue les rôles aux différents utilisateurs. La table Statut utilisateur permet de définir le statut des comptes utilisateurs. Ce dernier peut prendre différentes valeurs parmi lesquelles Activé, Désactivé, crée. La table Time job quand à elle permet de définir la base de temps de travail de l’utilisateur. Elle permet de modéliser la base de suivi du temps du salarié, selon qu’il est à temps plein ou à temps partiel. — Gestion des sociétés Pour gérer les sociétés, les tables Société, Licence et Statut société ont été créées. Cellesci permettent respectivement de gérer la liste des sociétés, les licences attribues à chaque société, ainsi que le statut de chaque société, qui peut comme pour les utilisateurs, peut prendre des valeurs telles que Activée, Désactivée, créée, Suspendue.

EURÊKA C.I

31

Strictement confidentiel

32 Figure 3.13 – La Base des données RDI MANGER, établie sur MySql Workbench

Université G. Eiffel

Rapport de Stage M2

— Gestion des projets Pour gérer les projets nous avons créé la table Projet qui recense tous les projets de la plateforme. Celle-ci est complétée par la table Statut projet qui définit le statut du projet. Celui-ci peut être les valeurs : en cours, terminé ou suspendu. La table Participants projet recense l’ensemble des membres des projets. Suivant le projet les participants peuvent avoir des rôles différents (Observateur, Participant et Chef de projet) qui sont recensés dans la table Rôle participant. Les tables Faits marquants et Fichier projet complètent la modélisation de la gestion des projets pour l’enregistrement des faits marquants et la sauvegarde des fichiers liés à chaque projet. — Gestion du suivi du temps Pour le suivi de temps, nous avons défini trois tables : - une pour la saisie du temps passé sur les différents projets, - une pour la saisie des jours d’absences et - une pour faire appel aux jours fériés de la période. L’ensemble de ces données sera par la suite traité pour générer la feuille de temps des différents utilisateurs. L’ensemble de cette modélisation architecturale de la base de données est présenté en figure 3.13. Les clés primaires y sont représentées par des icônes jaune, et les clés étrangères par des icônes rouge. — La logique relationnelle La logique relationnelle entre les différentes tables est définie par les relations 1 :1, 1 :N et N :N. Celles-ci symbolisent respectivement le fait que : - (1 :1) chaque uplet de la première table peut être en relation avec un seul uplet de la seconde table et inversement ; - (1 :N) un uplet de la première table peut être en relation avec plusieurs uplets de la seconde table, pendant que chaque uplet de la seconde table ne peut être en relation qu’avec un seul uplet de la première table ; - (N :N) chaque uplet de la première table peut être en relation avec plusieurs uplets de la seconde table et inversement. Dans le modèle développé en figure 3.13, on peut noter que la table Licence est liée à la table Utilisateur par une relation 1 :1, car un utilisateur ne peut avoir qu’une licence et une licence ne peut être attribuée qu’à un utilisateur. De même on peut noter que la table Projet est liée à la table Faits marquants par une relation 1 :N. Ceci modélise le fait qu’un projet peut avoir plusieurs faits marquants, alors qu’un fait marquant ne peut être lié qu’à un seul projet. Par ailleurs, le lien entre la table Utilisateur et la table Projet est un peu plus complexe. Celui-ci passe par une relation 1 :N entre la table Utilisateur et la table Participant projet ; qui elle-même est lié par deux liaison N :1 avec les tables Projet et Rôle participant projet. Ceci modélise le fait qu’un utilisateur peut être plusieurs fois participant dans plusieurs projets différents avec des rôles différents. En d’autres termes, un projet peut avoir plusieurs utilisateurs et un utilisateur peut participer à plusieurs projets différents avec à chaque fois un rôle lié au projet. C’est ainsi que les différentes tables de la base de données ont été modélisées et liées dans l’ensemble de l’architecture. Celle-ci a ensuite été intégrée dans la plateforme l’aide des fonctionnalités de gestion de base de données sous Symfony.

EURÊKA C.I

33

Strictement confidentiel

Chapitre 4 Développement de la plateforme La phase de développement peut être considérée comme étant l’aboutissement des différentes phases de conception de la plateforme et de modélisation de sa base de données. Il est question ici de coder les différentes interfaces d’utilisation, de les interconnecter suivant un parcours de navigation utilisateur, ainsi que d’y intégrer la base de données. Ces travaux incluent aussi l’intégration du module d’intelligence artificielle, ainsi que les différentes fonctionnalités d’alertes mobile et notifications mail destinées aux utilisateurs. Ces derniers points seront principalement traités lors de la phase de déploiement de l’application. Dans ce chapitre nous présentons l’approche de développement utilisée, ensuite nous illustrerons le résultat de développement par quelques illustrations de parcours utilisateurs sur la plateforme. Ensuite nous introduirons l’approche de déploiement prévue, ainsi que nos idées sur le développement du module d’intelligence artificielle.

4.1

Charte graphique

La charte graphique de développement de l’application est basée sur les standards d’image de marque EUREKA C.I. Ainsi, afin de de se conformer à ces standards, nous nous sommes inspirés de la charte graphique utilisée pour le site web du cabinet www.eurekaci.com ; à savoir le code couleur, le graphisme, le logo et la police du texte. Ensuite des particularités ont été rajouter afin d’avoir une image de marque propre à l’application. Il s’agit par exemple du logo de l’application RDI MANAGER qui est présenté dans la figure 4.4 ci-dessous avec ses variantes.

(a) Logo principal

(b) Sur fond rouge

(c) Sur fond noir

Figure 4.1 – Logo RDI Manager Nous avons choisi une approche épurée de présentation des interfaces (simples et ergono34

Université G. Eiffel

Rapport de Stage M2

miques), tant pour la visualisation des informations que pour le remplissage des formulaires. Ceci nous a amené vers un texte en noir sur un fond en blanc, avec des nuances de gris pour délimiter les zone d’intérêt de la page (formulaires, tableaux,...) ou les couleurs des menus déroulant et des boutons qui tendent vers du bleu-gris. Le tableau ci-dessous représente les grand axes du code couleurs utilisé pour la plateforme. Comme on peut voir en figure 4.4 ci-dessous, l’interface graphique de l’application RDI MANAGER s’inspire du site web EURÊKA. Le menu déroulant

Fond bleu-gris foncé et texte en blanc

L’entête et le pied des pages

Fond rouge foncé et texte en blanc

Les formulaires

Fond blanc et texte en noir

L’entête des tableaux

Fond rouge foncé et texte en blanc

Le contenu des tableaux

Fond blanc et texte en noir

Figure 4.2 – Couleurs du site web EURÊKA et de l’application RDI MANAGER

4.2

Développement des interfaces graphiques

La phase de développement des interfaces graphiques de l’application a commencé par la réalisation des maquettes des interfaces puis des digrammes de navigation (back-office, et front-office) de l’application. Ces diagrammes (figures 4.5 et 4.6) permettent d’avoir une vision globale de l’enchainement des écrans pour les utilisateurs. Ceci permet de mieux appréhender la future expérience utilisateur via l’analyse de l’arborescence de fonctionnalités utilisateurs back-office et front-office. Pour initier le codage, nous avons installé l’environnement intégré de développement Microsoft Visual Studio 2019, ainsi que l’outil Git sous différentes branches via le Github. Ceci permet de gérer les contribution des différents membre du projet et faciliter la gestion des modifications et mises à jour. Nous avons installé Xampp pour développer les premiers écrans de notre application. La bibliothèque (package) Xampp contient le langage de programmation PHP, le serveur de test EURÊKA C.I

35

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

local Apache friends et le logiciel de base de données MySql. En effet, comme précédemment énoncé, nous avons utiliser le langage de développement PHP pour le codage des interfaces. Ceci à permis dans notre cas d’avoir des pages Web dynamiques. Par ailleurs le framework bootstrap avec sa gestion du CSS nous a permis une meilleure gestion de l’aspect graphique à notre application. Les développements ont été réalisés sous le Framework Symfony. Il fournit beaucoup de fonctionnalités pour diminuer la quantité de code nécessaire à écrire, il est considéré comme un ensemble d’outils rassemblant des composants préfabriqués, ce qui accélère le développement de la plateforme et permet à d’autres développeurs de prendre en main rapidement le projet sans avoir participé à son élaboration. La principale spécificité de Symfony c’est son architecture MVC littéralement Modèle Vue Contrôleur. Il s’agit d’une architecture qui organise l’interface Homme-Machine de développement en différentes couches indépendantes. Il impose la séparation entre les données, la présentation et les traitements. Ceci a abouti à un développement en trois parties de l’application : le modèle de données, le contrôleur et la vue. — Le modèle : Permet d’enregistrer les données, de les récupérer, de les lister, de les supprimer, et de les mettre à jour. — La vue : La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa première tâche est de présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions de l’utilisateur (clic de souris, sélection d’une entrée, boutons, etc). Ces différents événements sont envoyés au contrôleur, la vue se contente d’afficher les résultats des traitements effectués par le modèle et d’interagir avec l’utilisateur. — Le contrôleur : Le contrôleur prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de l’utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle, et ce dernier transmet à la vue les données changées pour qu’elle se mette à jour. La figure 4.2 représente l’architecture MVC de notre application.

Figure 4.3 – Architecture MVC du framework Symfony L’une des difficultés rencontré dans ces développement sous symphonie était liée à la version 5. Celle-ci étant assez récente, ne dispose pas encore suffisamment de tutoriel dans la communauté des développeurs pour facilité son utilisation. En effet, après quelques difficultés à trouver des solutions de codage en ligne, nous nous sommes rabattus sur la version 4.4 qui en l’occurrence est largement éprouvée au sein de la communauté. Ces difficultés EURÊKA C.I

36

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

était par exemple lié à la gestion des authentification et des rôles des utilisateurs qui était particulièrement complexe sous Symfony V5. Avec la V4.4, nous avons utilisé le Bundle FOSUserBundle qui très pratique et très bien expliqué dans les tutoriels en ligne.

4.3

Intégration des composants associés

Dans cette partie des travaux, il est question d’intégrer les données et le module d’I.A au système d’information puis de développer les web-services et échanges avec le Back-office. Notre travail ici a principalement consisté à contribuer à l’intégration de la base de données à la plateforme. La durée du stage (6 mois y compris 2 mois en confinement) n’a pas permis d’aborder les aspects I.A et notifications mail et MMS. Cependant, nous avons quand même tenu à présenter notre vision de la chose.

4.3.1

Intégration de la base de données

L’implémentation de notre base de données est faite via l’ORM (Object Relational Mapping) du Framework Symfony 4.4 qui s’appelle Doctrine. Doctrine est un ORM (objectrelational mapping), c’est un ensemble de classes qui permet d’accéder aux contenus de la base de données. Il supporte des bases de données relationnelles comme MySQL et PostgreSQL ainsi que des bases de données NoSQL comme MongoDB. D’un côté un ORM est un programme qui définit des correspondances entre les schémas de la base de données et les classes du programme applicatif. On pourrait le désigner comme une couche d’abstraction entre le monde objet et monde relationnel. Avec Doctrine j’ai créé les tables qui correspondent aux formulaires et à la base de données, et ces tables ont été bien reliés grâce à ORM Doctrine, les opérations CRUD (ajout, modification, suppression) ont été facile à gérer. Les avantages de ce procédé sont nombreux : Cette approche permet de générer automatiquement à la fois les tables de la base de données et les objets php (classes) qui sont directement reliés aux tables créées. La persistance de ces objets sera gérée nativement par Doctrine (faisant office d’une couche d’abstraction de base de données ou DataBase Abstraction Layer). Cela permet également de générer automatiquement du code de qualité éprouvé, conforme aux standards et non buggé. Enfin en cas de la modification de la structure de la base de données si la modification se fait via Doctrine et non directement dans l’interface d’administration de la base de données (PHPMyAdmin), le code des classes métier qui sont liées aux tables s’adapte automatiquement, il « suit » les modifications apportées à la base de données. Contrairement à une approche classique où les modifications faites sur la structure de la base de données ne sont pas répercutées sur les classes métier qui y sont liées.

4.3.2

Approche envisagée pour la gestion des notifications

Les utilisateurs de l’application seront notifiés via deux canaux de communication, Email et SMS. — L’Email : des notifications de type push seront envoyées par email aux utilisateurs de l’application. Ces notifications contiendront un lien qui redirigera l’utilisateur notifié sur l’application sans qu’il n’ai besoin de rechercher le lien de RDI MANAGER. Son implémentation technique se fera de manière classique et gratuitement en utilisant la classe PHP Mailer en charge de la gestion de l’envoie des emails. EURÊKA C.I

37

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

— Le SMS : l’envoi de SMS sera similaire à l’envoi d’Emails au niveau de l’application sous Symfony. Les différences résident sur les points suivants : Nous utiliserons une bibliothèque PHP dédiée à l’envoi de SMS. Cette bibliothèque nous permettra de connecter RDI MANAGER à une plateforme spécialisée dans l’envoi de SMS. Cette plateforme facturera EURÊKA C.I. en fonction du volume mensuel de SMS envoyés.

4.3.3

Approche envisagée pour l’intégration du module d’I.A

Le module d’I.A se résumera par une analyse sémantique des données relatives à chaque projet, pour cela nous aurons : — Un référentiel de mots clés relatifs aux domaines de l’innovation et de la R&D. — Un algorithme qui s’effectuera pour chaque projet et donnera un score RDI. Le fonctionnement de l’algorithme pour chaque projet : — Scanner l’intégralités des données du projet : Titre et Faits marquants. — Compter le nombre de fois où chaque mot clé du référentiel apparait dans les données du projet. — Établir un score pour chaque projet en fonction du nombre de mots clés détectés dans les données du projet.

4.4

Approche envisagée pour le déploiement

Le déploiement d’une application logicielle répartie se réalise en fin de processus de développement ou avec un outil d’intégration continue. Il s’effectue sur un serveur de test et se formalise à partir d’un diagramme dit de déploiement. Ce diagramme modélise le matériel utilisé dans les implémentations système, ainsi que les environnements d’exécution et les artefacts 1 déployés sur le matériel. Dans le cas de notre projet, il se fera dans un premier temps dans le serveur EURÊKA C.I hébergé chez O2SWITCH. Nous avons pas eu le temps de réaliser cette partie des travaux dans le cadre du stage. Elle sera réalisée dans la continuité du développement par l’équipe technique de la société. Cependant, il sera important dans cette phase des travaux de bien prendre en compte les dépendances vis-à-vis des composants externes à l’application. Il s’agit ici par exemple de bien interconnecter la plateforme avec l’application d’envoi de notifications push. Enfin pour obtenir une application logicielle opérationnelle et sécurisée, cela se fait par la bonne gestion de la sécurité de l’application en termes de signature numérique des exécutables. Ceci passe en particulier par la réalisation d’un diagramme de déploiement. en perspective de notre travail de stage, nous proposons le diagramme de déploiement présenté en figure 4.4.

4.5

Illustration des développements réalisés

Dans cette dernière partie nous illustrons les principales interfaces graphiques de l’application. Leur développement a été présenté en section 4.2. Nous commençons par l’introduction de l’expérience utilisateur via les diagrammes des chemins de fonctionnalités back 1. un artefact est une manière de définir un fichier, un programme, une bibliothèque ou une base de données construite ou modifiée dans un projet

EURÊKA C.I

38

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Figure 4.4 – Proposition diagramme de déploiement RDI MANAGER et front (figure 4.5 et 4.6) avant de présenter les interfaces réalisées des parcours back-office et front-office.

EURÊKA C.I

39

Strictement confidentiel

40 Figure 4.5 – Chemin des fonctionnalités back-office

41 Figure 4.6 – Chemin des fonctionnalités front-office

Université G. Eiffel

4.5.1

Rapport de Stage M2

Parcours utilisateur back-office

— Interface de connexion La première interface qui s’affichent pour tous les utilisateurs Back-Office lorsqu’ils rejoignent l’application et celle de connexion. Elle permet de s’authentifier en saisissant son identifiant et son mot de passe. En cas d’oubli de son mot de passe, l’utilisateur clique sur mot de passe oublié ; il reçois immédiatement un e-mail qui lui permet de récupérer son mot de passe.

Figure 4.7 – Interface de connexion — Interface d’ajout de société Cette interface permet l’ajout d’une société sous la plateforme par saisie de ses informations. elle n’est accessible qu’au Référent société back-office ou Administrateur. Les informations d’ajout de société ici sont : le Nom de société , son Siret, le Référent back office de la société, Référent front-office de la société et le nombre de licences utilisateur mises à sa disposition.

Figure 4.8 – Interface d’ajout de société — Ajout d’un utilisateur back-office EURÊKA C.I

42

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Le formulaire d’ajout utilisateur Back-office permet de saisir le nom, prénom, Email, rôle et statut d’un nouvel utilisateur. Seul l’administrateur a le droit d’ajout des utilisateurs.

Figure 4.9 – Interface de la liste des utilisateurs — Visualisation de la liste des utilisateurs back-office La liste des utilisateurs est visible par l’ensemble des utilisateurs back-office. Elle contient les informations relatives aux nom, prénom, email, rôle sous la plateforme et statut des différents utilisateurs. Seul l’administrateur à les droits de modification et de suppression des utilisateurs.

Figure 4.10 – Interface de la liste des utilisateurs

EURÊKA C.I

43

Strictement confidentiel

Université G. Eiffel

4.5.2

Rapport de Stage M2

Parcours utilisateur front-office

— Interface de connexion front-office L’interface de connexion front-office est basée sur le même principe que celle en Backoffice : La connexion se fait par saisi de l’identifiant et le mot de passe de l’utilisateur.

Figure 4.11 – Interface de connexion — Interface d’accueil front-office La page d’accueil de l’utilisateur est constituée d’un tableau de bord qui affiche l’ensemble des informations concernant les projets RDI pour lesquels celui-ci a un droit de regard. Il affiche également des diagrammes indiquant des informations globales sur l’activité RDI durant les trois dernières années. On peut citer par exemple nombre de projets réalisés et leurs statuts (encours, terminé et suspendu), le nombre de projets réalisés chaque année en mettant en évidence leurs qualification RDI ou non.

Figure 4.12 – Tableau de bord EURÊKA C.I

44

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

— Management d’un projet Dans cette interface l’utilisateur ayant droit peut visualiser les informations relatives à la gestion d’un projet donné. Le projet est identifié par son acronyme, et sa description est donnée par son titre, son résumé, sont statut, son chef de projet, sa date début et sa date de fin. Sa gestion est illustrée par ses faits marquants, ses pièces jointes, et sa liste de participants. En fonction de ses droits d’accès au projet, l’utilisateur peut (via des fenêtres de type pop-up) modifier les informations du projet, gérer les participants, ajouter de faits marquants au ajouter des pièces jointes au projet.

Figure 4.13 – Contenu du projet — Suivi du temps RDI utilisateur Le suivi du temps RDI des utilisateurs se fait via l’interface de saisie du temps passé par l’utilisateur sur chacun des projets auxquels il participe. Celui-ci est fait de préférence mensuellement et la saisie du temps passé se fait en pourcentage.

EURÊKA C.I

45

Strictement confidentiel

Université G. Eiffel

Rapport de Stage M2

Figure 4.14 – Interface de saisie de temps RDI — Suivi des absences Le suivi du temps RDI des utilisateurs est optimisé en prenant en compte leur jours d’absence au cours de chaque période mensuelle. Le calendrier des jours d’absence tiens en compte des jours fériés qui s’affiche en gris. L’utilisateur peut alors saisir et valiser ses absences de la période par unités de d’une demi-journée.

Figure 4.15 – Interface de saisie des jours d’absences

EURÊKA C.I

46

Strictement confidentiel

Chapitre 5 Conclusion Générale Ce stage de Master 2 au sein du cabinet EURÊKA C.I m’a permis de travailler dans un projet d’entreprise à fort enjeux technique, opérationnel et stratégique. Ce projet, RDI Manager, est en fait au coeur de la stratégie de renforcement de l’offre conseil du cabinet. En effet, en participant (en qualité d’observateur) à quelques missions de conseil en innovation du cabinet, j’ai pu découvrir le métier de conseil en innovation et mieux comprendre les enjeux de l’innovation au sein des entreprises, et en particulier les PEM et TPE. J’ai ainsi mieux appréhendé le sujet de stage qui consistait au développement d’un outil simple et efficace de management de l’activité RDI (Recherche, Développement et Innovation) au sein des PME et TPE. Les travaux développement de cet outil numérique m’ont permis de me confronter à un domaine d’ingénierie auquel je n’étais pas particulièrement habitué. J’ai ainsi pu apprendre la méthodologie de développement d’un projet informatique de type application web ; travailler dans la conception des bases de données et réfléchir aux questions liées au déploiement cloud d’une plateforme numérique. J’ai ainsi renforcé mes compétences en développement web, appris de nouveau langage de développement et utilisé les plus récentes et plus performantes Frameworks issues de la communauté des développeurs. Il s’agit par exemple des Frameworks Symfony du langage PHP, Bootstrap de CSS et HTML et InnoDB de MySql. Dans la continuité de ces travaux de développement, j’aurai bien voulu participer aux travaux de développement du module d’intelligence artificiel de la plateforme. Il en est de même pour le développement de la couche métier de la plateforme, ainsi que l’intégration des systèmes push d’alertes et relances mail et mobile. Ces différents points du projet RDI Manager font partie des perspectives du stage, auxquelles j’ai émis des idées pour la suite. En effet, outre le fait que la durée du stage ne me permettait pas d’aller jusqu’au bout du projet ; la crise sanitaire liée à l’épidémie du coronavirus Covid-19, a été d’un grand handicap dans l’avancement du stage. L’encadrement du stage à distance, en confinement a été particulièrement difficile. Ceci était principalement dû au fait que discuter des questions techniques complexes à distance est loin d’être simple et confortable. Sur le plan socio-professionnel, outre le travail en équipe qui a contribué à développer mes aptitudes et compétence professionnelles ; j’ai pu vivre une véritable expérience professionnelle au sein du cabinet EURÊKA C.I. J’ai en effet côtoyer des collègues de haut niveau tant sur le plan social que professionnel. En somme, ce stage au sein du cabinet EURÊKA C.I m’aura permis de renforcer mes 47

Université G. Eiffel

Rapport de Stage M2

compétences en développement numérique, tout en contribuant à enrichir mon expérience professionnelle.

EURÊKA C.I

48

Strictement confidentiel

Bibliographie [1] Alain Cazes, Joëlle Delacroix ; Développer une application web ; ISBN 978-2-10-0743759, Edition Dunod, 2016 [2] André Le Garff, Dictionnaire de l’informatique, Édité par Presses Universitaires De France (puf), Paris, 1975, 576 p. [3] Base de données Système de gestion de base de données MySQL / SQL, PHP-MYSQL ; OOV-php-mysql-mpT-janv.2004, Doc-développement-durable.org / cours-&-manuelsinformatiques, consulté en 2020 [4] Bercy Infos ; Tout savoir sur le crédit impôt recherche (CIR) ; economie.gouv.fr, 15 Juin 2020. [5] Camille Regnault ; Développement Symfony et expertise à Lyon ; AXOPEN mars 2020 , https ://blog.axopen.com consulté en 2020 [6] Encyclopédie Larousse ; Édition Librairie Larousse (Paris) 2020 [7] EURÊKA C.I ; site web, documents et note internes Eureka ; consulté en 2020 [8] Genius Inside ; Genius Project : Planifier pour réussir ; https ://www.geniusproject.fr/ , consulté en 2020 [9] GRYZZLY ; CIR & CII : Automatisez la collecte du temps passé en R&D ; https ://www.gryzzly.io/cir/ , consulté en 2020 [10] IUT de Nice - Département INFORMATIQUE ; Concepts et langages des Bases de Données Relationnelles ; SUPPORT DE COURS, consulté en 2020 [11] LABOXY SAS ; LabOxy, la plateforme en ligne dédiée à votre R&D et son financement ; https ://www.laboxy.fr/ , consulté en Aout 2020 [12] Leyton France ; Logiciel R&D Tracker : une plateforme collaborative innovante ; https ://www.leyton.com/fr/france/expertise/logiciel-rd-tracker consulté en 2020 [13] Michael Kofler (2005), MySQL 5 : Guide de l’administrateur et du développeur (ISBN 978-2-212-11633-5) [14] Microsoft Project ; Découvrez le nouveau Project : simple, performant et repensé ; https ://www.microsoft.com/fr-fr/microsoft-365 , consulté en 2020 [15] Ministère de l’enseignement supérieur de la recherche et de l’innovation ; Guide du crédit d’impôt recherche ; esr.gouv.fr, 15 Juin 2020. [16] Mohamed Cherchem ; L’innovation dans les services comme un pilier de l’économie fondée sur la connaissance ; cas des banques et des assurances algériennes, La Revue des Sciences de Gestion 2011/1-2 (n°247-248), pages 29 à 37. 49

Université G. Eiffel

Rapport de Stage M2

[17] Pierre Liseron ; JAVA vs PHP pour la création d’une application web ou site web ; AXOPEN juin 2014 , https ://blog.axopen.com consulté en 2020 [18] Pierre Mohnen ; L’efficacité des aides publiques à la R&D et à l’entreprenariat ; ECONOMIE ET STATISTIQUE N° 493, 2017. [19] Planisware ; Planisware Enterprise ? Fonctionnalités : Découvrez les fonctionnalités clés de Planisware Enterprise ; https ://fr.planisware.com/enterprise/fonctionnalites-produit , consulté en 2020 [20] REDMINE ; Redmine : un outil de gestion de projet open source ; https ://www.journaldunet.fr/web-tech et www.redmine.org , consultés en 2020 [21] Stackoverflow ; Developer Survey Results ; sights.stackoverflow.com/survey/2016#top, consulté en 2020

https

://in-

[22] TechCrunch ; The Challenges Of Building AI Apps ; https ://techcrunch.com/ , consulté le 21 juillet 2020

EURÊKA C.I

50

Strictement confidentiel

Appendices

51

Annexe A : Tâches réalisées au cours du stage

52 Figure 1 – Tâches principales effectuées au stage

Université G. Eiffel

Rapport de Stage M2

Annexe B : Acronymes utilisés CSS : Feuilles de style en cascade HTML : Hypertext Markup Language IA : Intelligence artificielle ISO : Organisation internationale de normalisation JEE : Java Enterprise Edition JVM : Machine virtuelle Java PHP : Hypertext Preprocessor SGBD : Système de gestion de base de données SQL : Structured Query Language UML : Unified Modeling Language XML : Extensible Markup Language

EURÊKA C.I

53

Strictement confidentiel