Rapport de Stage Eureka BAZZAR V2

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 : Tuteur d’entreprise :

Ader BAZZAR M. Sylvain CLEMENT
Resp. Académique : Chef Projet :
Karim FRAOUA, PhD 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’in-
novation 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 mo-
dè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 socio-
professionnel. 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 parti-
culier 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 promo-
tion 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 3
2 EURÊKA C.I et le projet RDI Manager 6

2.1 Le cabinet EURÊKA C.I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Les principales missions conseil du cabinet . . . . . . . . . . . . . . . 7
2.1.2 Enjeux d’innovation au sein des PME . . . . . . . . . . . . . . . . . . 9
2.2 Le Projet de Stage : RDI Manager . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 État du marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Conception technique de la plateforme 20

3.1 Spécifications de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1 Spécifications fonctionnelles . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.2 Spécifications techniques . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Modélisation des scénarios nominaux . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Diagrammes de cas d’utilisation . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Diagrammes de séquences . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3 Conception architecturale de la BDD . . . . . . . . . . . . . . . . . . . . . . 30
4 Développement de la plateforme 34
4.1 Charte graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Développement des interfaces graphiques . . . . . . . . . . . . . . . . . . . . 35
4.3 Intégration des composants associés . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Intégration de la base de données . . . . . . . . . . . . . . . . . . . . 37
4.3.2 Approche envisagée pour la gestion des notifications . . . . . . . . . . 37
4.3.3 Approche envisagée pour l’intégration du module d’I.A . . . . . . . . 38
4.4 Approche envisagée pour le déploiement . . . . . . . . . . . . . . . . . . . . 38
4.5 Illustration des développements réalisés . . . . . . . . . . . . . . . . . . . . . 38
4.5.1 Parcours utilisateur back-office . . . . . . . . . . . . . . . . . . . . . . 42
4.5.2 Parcours utilisateur front-office . . . . . . . . . . . . . . . . . . . . . 44
5 Conclusion Générale 47
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Références Bibliographiques : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Appendices 51
1
Table des figures
2.1 Organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 L’offre de conseil EURÊKA C.I [7] . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Analyse des produits concurrents sur le marché . . . . . . . . . . . . . . . . 13
2.4 Positionnement de RDI Manager vis-à-vis de la concurrence . . . . . . . . 14
2.5 Analyse SWOT de la plateforme RDI Manager . . . . . . . . . . . . . . . . . 14
2.6 Principaux modèles de base de données, inspiré de [10, 3] . . . . . . . . . . . 17
3.1 Tableau des acteurs back-office et leurs descriptions fonctionnelles . . . . . . 21

3.2 Tableau des acteurs front-office et leurs descriptions fonctionnelles . . . . . . 21
3.3 Rôles, attributions et droits des acteurs-utilisateurs Front & Back office . . . 22
3.4 Présentation modulaire des fonctionnalités RDI Manager . . . . . . . . . . . 23
3.5 Scénarios de gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Scénarios de gestion des sociétés . . . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Les scénarios de gestion des projets . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Scénarios de suivi des temps . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Illustration de la séquence de connexion d’un Observateur . . . . . . . . . . 28
3.10 Illustration d’une séquence de modification des informations société . . . . . 29
3.11 Illustration d’une séquence d’activation de compte utilisateur front-office . . 30
3.12 Illustration d’une séquence de visualisation de faits marquants d’un projet . 30
3.13 La Base des données RDI MANGER, établie sur MySql Workbench . . . . . 32
4.1 Logo RDI Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Couleurs du site web EURÊKA et de l’application RDI MANAGER . . . . . 35
4.3 Architecture MVC du framework Symfony . . . . . . . . . . . . . . . . . . . 36
4.4 Proposition diagramme de déploiement RDI MANAGER . . . . . . . . . . . 39
4.5 Chemin des fonctionnalités back-office . . . . . . . . . . . . . . . . . . . . . 40
4.6 Chemin des fonctionnalités front-office . . . . . . . . . . . . . . . . . . . . . 41
4.7 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.8 Interface d’ajout de société . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.9 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 43
4.10 Interface de la liste des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . 43
4.11 Interface de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.12 Tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.13 Contenu du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.14 Interface de saisie de temps RDI . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.15 Interface de saisie des jours d’absences . . . . . . . . . . . . . . . . . . . . . 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’en-
treprises 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 so-
phistiqué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 pro-
cessus 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’émer-
gence 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 im-
posent des approches spécifiques dans le développement des logiciels de manage-
ment. 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éve-
loppement 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 densi-
fication 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 parti-
culiè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 manage-
ment 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 non-
né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 col-
laboratif 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 - Ap-
proche intelligente de pilotage.
A travers ce projet de développement numérique, le cabinet EURÊKA C.I veut contri-
buer à 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

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éve-
loppement 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 plate-
forme 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.

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 accom-
pagne 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 consul-
tants de formation doctorale, expérimentés et dynamiques. Il compte depuis peu trois bu-
reaux 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, Franche-
Comté).
— 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
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 contact@eurekaci.com
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

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 in-
novantes (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 recru-
tement 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

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 en-
treprises (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 mu-
nicipales (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.

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, collabo-
rative, 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 in-
novantes 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’avan-

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. Celui-
ci 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’appli-
cations numériques sur le marché. Celles-ci peuvent être classées en deux groupes vis-à-vis
de RDI Manager.

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 pro-
jets) 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.

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é.

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 sim-
plifié 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 notifi-
cations 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

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éa-
liser 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 ser-
veur 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éveloppe-
ment 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

(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 Sys-
tè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 arbo-
rescence descendante. Ce modèle utilise des pointeurs entre les différents enregistre-
ments. 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

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 ensem-
blistes, 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 relation-
nels).
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 don-

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. Celle-
ci 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 abs-
traites ; 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’in-
gé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’algo-
rithmes 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 pre-
mier 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’or-

dinateur la capacité d’apprendre à partir de données. Ceci suppose d’améliorer les per-
formances 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.

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’ap-
plication. 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 appor-
té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’EU-
RÊ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 des-
criptions fonctionnelles.
20
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 inter-
face 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 des-
criptions 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 re-
groupé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 fonc-
tionnalité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.

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

3.1.2 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 tech-
nologies é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 ma-
niè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 trai-
tement, 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

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’ap-
plication 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 fonc-
tionnel 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’utilisa-
tion, 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 -

ajouter, modifier, supprimer un utilisateur de ses sociétés, et - visualiser la liste des utili-
sateurs 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

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

3.2.2 Diagrammes de séquences

Les diagrammes de séquences représentent graphiquement les interactions entre les ac-
teurs 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’authentifica-
tion, 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

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.

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 :

— Une première approche conceptuelle. Celle-ci représente le contenu de la base de don-

né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éli-
sation 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 front-
office 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. Celles-
ci 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.

32
Figure 3.13 – La Base des données RDI MANGER, établie sur MySql Workbench
— 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.

Chapitre 4
Développement de la plateforme
La phase de développement peut être considérée comme étant l’aboutissement des dif-
fé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 tra-
vaux 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 particu-
larité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 ergono-
34
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 plate-
forme. 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

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éveloppe-
ment 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 or-
ganise 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 pre-
miè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 en-
tré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 synchro-
nisation 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 diffi-
culté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

é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 Map-
ping) du Framework Symfony 4.4 qui s’appelle Doctrine. Doctrine est un ORM (object-
relational 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 Post-
greSQL 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’abs-
traction 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 qua-
lité é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 ap-
porté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.

— 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’ap-
plication. Leur développement a été présenté en section 4.2. Nous commençons par l’intro-
duction 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

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.

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

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

4.5.1 Parcours utilisateur back-office

— Interface de connexion
La première interface qui s’affichent pour tous les utilisateurs Back-Office lorsqu’ils re-
joignent 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 in-
formations. 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

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

4.5.2 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 Back-
office : 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’en-
semble 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’acti-
vité 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

— 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.

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

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 inno-
vation 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 ap-
prendre 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 profes-
sionnelle 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
compétences en développement numérique, tout en contribuant à enrichir mon expérience

professionnelle.

Bibliographie
[1] Alain Cazes, Joëlle Delacroix ; Développer une application web ; ISBN 978-2-10-074375-
9, 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-&-manuels-
informatiques, 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
[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 ; ECO-
NOMIE 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 ; https ://in-
sights.stackoverflow.com/survey/2016#top, consulté en 2020
[22] TechCrunch ; The Challenges Of Building AI Apps ; https ://techcrunch.com/ ,
consulté le 21 juillet 2020

Appendices
51
Annexe A : Tâches réalisées au cours du stage
52
Figure 1 – Tâches principales effectuées au stage

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

Langue

Rapport de Stage Eureka BAZZAR V2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Stage Eureka BAZZAR V2

Transféré par

Droits d'auteur :

Formats disponibles

MASTER INTELLIGENCE ECONOMIQUE

Parcours : Analyse, Management des Données et Innovation

Développement d’une plateforme

Étudiant : Tuteur d’entreprise :

1er Mars 2020 - 31 Août 2020

Dans le cadre du développement d’un outil de management de l’innovation destiné aux

2 EURÊKA C.I et le projet RDI Manager 6

3 Conception technique de la plateforme 20

2.1 Organigramme de la société . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1 Tableau des acteurs back-office et leurs descriptions fonctionnelles . . . . . . 21

4.1 Logo RDI Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

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

EURÊKA C.I 4 Strictement confidentiel

EURÊKA C.I 5 Strictement confidentiel

EURÊKA C.I et le projet RDI

2.1 Le cabinet EURÊKA C.I

Dénomination EURÊKA C.I

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

2.1.1 Les principales missions conseil du cabinet

EURÊKA C.I 7 Strictement confidentiel

politique d’innovation et de développement. Outre ces trois principales missions, le cabinet

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

Le management stratégique de l’innovation

EURÊKA C.I 8 Strictement confidentiel

La politique d’innovation et de développement

2.1.2 Enjeux d’innovation au sein des PME

EURÊKA C.I 9 Strictement confidentiel

2.2 Le Projet de Stage : RDI Manager

EURÊKA C.I 10 Strictement confidentiel

Créer, modifier et supprimer un projet Visualiser la liste des projets

Un tableau de bord associé au front-end utilisateur donnera des informations générales

Créer, modifier et supprimer une société Visualiser la liste des sociétés

Comme on peut le constater, la plateforme RDI Manager a pour ambition d’apporter

2.2.1 État du marché

EURÊKA C.I 11 Strictement confidentiel

EURÊKA C.I 12 Strictement confidentiel

Figure 2.3 – Analyse des produits concurrents sur le marché

EURÊKA C.I 13 Strictement confidentiel

Figure 2.4 – Positionnement de RDI Manager vis-à-vis de la concurrence

Figure 2.5 – Analyse SWOT de la plateforme RDI Manager

EURÊKA C.I 14 Strictement confidentiel

2.2.2 État de l’art

- Développement d’applications web

EURÊKA C.I 15 Strictement confidentiel

- Base de Données et Système de Gestion de base de données

EURÊKA C.I 16 Strictement confidentiel

les bases de données dites spécialisées (documentaires ou géographiques) où les schémas

Figure 2.6 – Principaux modèles de base de données, inspiré de [10, 3]

EURÊKA C.I 17 Strictement confidentiel

EURÊKA C.I 18 Strictement confidentiel

EURÊKA C.I 19 Strictement confidentiel

Dans ce chapitre nous présentons la conception architecturale globale de la plateforme

3.1 Spécifications de l’application

3.1.1 Spécifications fonctionnelles

Figure 3.1 – Tableau des acteurs back-office et leurs descriptions fonctionnelles

Figure 3.2 – Tableau des acteurs front-office et leurs descriptions fonctionnelles

EURÊKA C.I 21 Strictement confidentiel

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

3.1.2 Spécifications techniques

EURÊKA C.I 24 Strictement confidentiel

3.2 Modélisation des scénarios nominaux