L’analyse de terrain IS, à Schneider Electric 

Choix entre développement spécifique ou progiciel : la théorie

« La théorie, c’est quand on sait tout et que rien ne fonctionne […] » A. Einstein Dans le but d’identifier et de cerner correctement les thématiques existantes en terme de développement spécifique et progiciel, il convient tout d’abord de réaliser un état de l’art.
Pour cela nous définirons les termes importants de notre sujet, puis grâce à l’analyse d’études de cas, nous identifierons les principales thématiques autour desquelles on analyse les avantages et contraintes des deux solutions.

Définitions

Notion de logiciel et développement spécifique

En informatique, nous pouvons définir un logiciel spécifique comme un logiciel développé spécifiquement pour répondre à un besoin dans une organisation donnée.
Un logiciel spécifique ou sur mesure est donc un logiciel conçu par ou pour une entreprise et développé par cette entreprise, ou par un tiers pour cette entreprise.
Ainsi, le développement de logiciel sur mesure ou développement spécifique est l’action qui consiste à créer ce logiciel.
Le développement spécifique doit prendre en compte l’activité de l’entreprise, son contexte, son environnement et ses besoins spécifiques.
L’objectif final de ce type de développement est d’aider l’entreprise à mieux gérer certains aspects de son activité. Son principe est de permettre de créer un logiciel qui soit pleinement intégré à cette activité. De cette façon, il est possible de développer toute sorte de logiciel pour soutenir les grandes fonctions de l’entreprise (gestion, commerciale, SCM, gestion de stocks, CRM, workflow, gestion de projets, ressources humaines…).
Le logiciel ainsi créé dispose d’une spécificité propre à l’entreprise puisqu’il a été conçu exclusivement pour cette entreprise.

Etude de cas : « Faut-il développer soi-même en PME ? »

Le site Developpez.com a été contacté par la journaliste Aurélie Chandèze, dans le but de récupérer des témoignages autour du thème : « Faut-il développer soi-même en PME? ». Ce recueil a fait l’objet d’un article, qui recense les propos d’Aurélie Chandèze ainsi que les commentaires de membres de l’equipe Developpez.com.
Dans cette étude de cas, la journaliste nous présente la mise en place d’une application métier au sein de trois PME : la Mutuelle des Motards, Rousselon et Playmobil France.
Plus précisement elle cherche à analyser la démarche entreprise par les societés afin de choisir entre deux possibilités, l’achat d’un progiciel ou la réalisation d’une application sur mesure.
La Mutuelle des Motards, PME de 350 salariés et spécialiste de l’assurance 2-roues et de la protection des conducteurs de moto et scooter souhaite moderniser son système d’information.
Le métier de cette entreprise diffère de celui des assureurs traditionnels, notamment à cause du risque élevé d’accidents corporels chez ses sociétaires.
Le besoin metier est donc très specifique, et le responsable des systèmes d’information de l’entreprise, Thierry Caillard, déclare alors la necessité de refondre l’outil existant : « le type de dommages était mal pris en compte dans les progiciels du marché […] aucun progiciel pour l’assurance ne répond vraiment à ses besoins. »
La société a choisi d’opter pour une solution mixte . Pour elle un progiciel, qui permet de gérer les principales règles metiers en offrant plusieurs modules du nouveau système d’information, tout en gardant une ouverture pour une personnalisation est la solution idéale. Thierry Caillard déclare ainsi que « l’autonomie qu’apportent ces développements sur mesure est un avantage, ce n’est plus l’organisation qui s’adapte à l’outil, mais l’outil qui est conçu pour répondre à nos besoins ».

L’analyse de terrain IS, à Schneider Electric

« Ne pas planifier, c’est programmer l’échec. » A. France
Afin d’apporter une autre vision concernant le choix entre développement spécifique et progiciel, nous allons analyser la mise en place d’un système de génération de données en masse pour différents SI à Schneider Electric. Pour cela nous établirons le contexte de cette mission réalisée au sein de l’équipe IS, puis nous étudierons la démarche mise en place pour mener à bien ce développement. Enfin nous aborderons les différents critères de décision, les arguments, contraintes et avantages recensés lors de la mission.

Le contexte de la mission

Lors d’une mission où un besoin informatique est identifié, la question du choix de la solution à développer se pose. C’est la problématique que j’ai pu rencontrer lors de la mission effectuée au sein du service IS de l’entité Project Engineering Center (PEC) de Schneider Electric France.
La mission consistait à mettre en place un système de génération de données en masse pour différents systèmes d’information de PEC.
Un besoin informatique a tout de suite été constaté, le principe était de s’appuyer sur des mécanismes de chargement existants pour chaque SI, pour d’une part transformer les données de départ dans un format compatible avec ces mécanismes, et d’autre part pour proposer dans la mesure du possible une interface commune à tous les SI.
Ce besoin défini à l’origine du projet nous a conduit à une démarche de développement informatique. De ce fait, il nous amène au cœur de notre questionnement : quelle est la solution informatique adéquate à mettre en place ?
C’est donc dans le but de répondre à cette question que nous avons mis en place une démarche de projet.

La démarche mise place

De l’analyse jusqu’au questionnement : développement spécifique ou progiciel ?

Afin de proposer une solution adaptée et fonctionnelle, il a fallu établir une démarche projet et un planning à suivre.
Nous sommes tout d’abord passés par des phases d’analyses, nous permettant ainsi de cerner de façon complète le besoin identifié. Des analyses du contexte et de l’existant ont été effectuées, ce qui nous a permis une familiarisation avec les SI du périmètre étudié . Nous avons également réalisé un diagnostic du système à l’étude consistant d’une part à l’identification et la compréhension des mécanismes de chargement concerné par l‘étude (quels mécanismes de chargement ? quelles données engagées ? quelles procédures et quels cas d’utilisations ?) , et d’autre part il a fallu identifier et analyser les « scénarios ». Les scénarios sont des processus avec des données d’entrée et de sortie, des règles métier et de conversion. Ce sont ces scénarios que nous voulions industrialiser en mettant en place une solution informatique.
Ce n’est qu’à partir du recueil des besoins et des analyses accomplies, que nous avons pu commencer à imaginer vers quel type de solution nous souhaitions nous diriger. Puis dans le but de préciser et d’exprimer en détails ces règles définissant les scenarios, nous avons entamé un travail sur les spécifications.

Démarche en terme de management

Dans une démarche projet, la dimension de planning et de respect du délai est un principe important. Dans notre analyse des critères de décision à prendre en compte dans le choix entre développement spécifique et progiciel, le délai fait parti d’un de ces critères à considérer.
Au cours de la mission, nous avons du repousser la phase de développement de l’outil car le choix de la solution n’était pas encore arrêté (choix entre la solution ETL Pentaho ou développement Excel VBA). En effet, des erreurs apparues en préproduction sur la maquette ETL remettaient gravement en cause la faisabilité même de l’application souhaitée, ainsi que des incertitudes concernant des fonctionnalités indispensables dans l’environnement « cible ».
Suite à ce genre d’événement, une bonne réactivité est primordiale, ainsi une réunion a été rapidement organisée, et nous avons décidé de mettre en place un retro-planning.
Un retro-planning est une planification inversée, conçu en partant de la date de fin du projet puis en remontant dans le temps afin de positionner les jalons. Il est quelquefois plus facile d’utiliser cette méthode pour réaliser une planification, lorsque la date de fin de projet est fixée et inébranlable.
Nous avons défini un jalon de début de développement, soit la date au plus tard à partir de laquelle une solution pouvait être développée et permettait de produire une application qui soit fonctionnelle à la fin de la mission. De ce fait, nous avons pu identifier une date de décision (un jalon) à partir de laquelle le choix de la solution à mettre en œuvre devait être fait.
La marge de manœuvre ainsi disponible nous a permis de continuer notre phase de maquettage, afin de prendre la meilleure décision possible quant à la solution à mettre en œuvre, tout en garantissant un livrable a la fin du projet.

Résultats

En tenant compte de la contrainte de la marge de manœuvre disponible nous avons effectué des recherches, réalisé des modifications et de nombreux tests sur la maquette ETL Pentaho (serveur pré-production), afin de chercher à résoudre ces problèmes qui entamaient la faisabilité de la solution.
La réalisation de ces fonctionnalités requises sur la maquette ETL Pentaho, a permis de clore la phase de maquettage, et nous a permis d’effectuer notre choix entre la solution progiciel (ETL) ou le développement spécifique (application Excel macro VBA).
Après avoir étudié les maquettes sous différents critères et analysé tout les arguments (cf. partie suivante : 2.3) nous avons choisi de développer la solution progiciel ETL Pentaho.
Cette solution, ETL Pentaho, est un module appartenant à la suite Pentaho, une suite logicielle décisionnelle complète ayant pour principal objectif d’effectuer la distribution de diverses fonctionnalités à plusieurs utilisateurs par l’intermédiaire d’une interface web. Pentaho est un progiciel de gestion intégré qui s’inscrit dans la famille des logiciels open source.
Le progiciel Pentaho se compose de plusieurs modules, la présence d’un de ces modules dans le service IS, a favorisé le choix quant à intégrer un second module de la même suite logicielle. En effet le portail Pentaho nommé Business Intelligence Server a été mis en place en 2013 dans le cadre d’une mission de stage. Ce portail, utilisé par l’équipe IS dans le but de réaliser des analyses de données servira également d’interface web pour l’outil ETL que nous souhaitons à mettre en place.
En définitive, le développement de la solution se décomposera en plusieurs tâches : Il faudra installer et paramétrer le module ETL, nommé Pentaho Data Integration, un outil d’alimentation et de transformation ETL. Puis nous devrons paramétrer le module/portail Pentaho déjà en place afin de pouvoir utiliser l’interface web.

La confrontation de la théorie et de la pratique

« In theory, there is no difference between theory and practice. In practice, there is. » Y.Berra
Dans l’objectif de proposer une démarche à suivre et une réponse quant aux critères de décision à prendre en compte dans le choix entre développement spécifique et progiciel, nous allons maintenant confronter les apports des arguments mis en lumière grâce à l’analyse théorique et ceux recensés grâce à l’expérience de terrain.

Analyses et comparaison des arguments théoriques et pratiques

Les thématiques et arguments

Avant de choisir, il faut connaître son besoin, c’est là le principe fondamental à toute démarche de développement. Que le projet s’oriente vers une solution progicielle ou vers un développement spécifique, le premier critère à prendre en compte avant de prendre une décision, est le besoin du client.
Un argument également très présent dans la littérature concerne les fonctionnalités de l’outil à développer. En effet le niveau d’adaptabilité de l’outil au besoin, est primordial à définir. Il est important de connaitre le degré d’adéquation nécessaire entre les besoins et attentes du client et les fonctionnalités qu’il est possible de mettre en place. Quelles sont les principales fonctionnalités indispensables au futur outil ? en matière de faisabilité ? Quelle interface d’utilisation souhaitons-nous avoir ? en termes d’ergonomie mais aussi pour l’interface client-outil ? Autant de questionnements qui nous ont été décisifs dans notre choix de développement lors de la mission au sein de Schneider.
Il faut également identifier s’il est essentiel ou non pour le projet que l’outil contienne exclusivement le besoin de l’entreprise. Ainsi, dans certaines entreprises qui ont opté pour un progiciel, l’utilisation réelle de l’outil concernait seulement 5 à 20 % de ses fonctionnalités. Un développement spécifique aurait pu répondre aussi rapidement aux attentes sans ajouter de fonctions inutiles, mais l’entreprise a choisi un progiciel car ce type de développement correspondait à ses besoins et sa stratégie.
La problématique des ressources disponibles est un critère très important à prendre en compte. Il est primordial d’allouer les ressources adéquates au projet, que se soit en termes de ressources informatiques, financières ou de ressources métier, il faut les identifier.
Ensuite en fonction de ces ressources mises à disposition, nous allons continuer notre démarche pour réaliser notre choix entre un développement spécifique ou progiciel.
Parfois ce critère est un élément déterminant dans la décision de développement. C’est le cas de plusieurs PME qui choisissent des progiciels au détriment d’une application montée en interne par défaut de ressources en interne pour faire le développement.
Lors de la mise en place d’un système de génération de données en masse à SchneiderElectric, la compétence du développeur (et des membres de l’équipe IS en matière de développement) était un des facteurs clé dans le processus de décision. Cependant la particularité de la mission (un stage) nous a menés vers un autre aspect que le simple savoir-faire de la ressource. En effet lors d’un stage, la notion d’apprentissage est à intégrer, et gagner en compétences sur une nouvelle démarche, sur une technique ou solution représente un grand intérêt.
Les concepts de pérennité, maintenabilité de l’outil et de réactivité sont essentiels à considérer. Le niveau de maintenabilité est un élément qui a été étudié lors de la mission. La solution à mettre en place devait être supportée par une technologie stable, et elle devait pouvoir être maintenue par l’utilisateur (équipe IS). Ainsi de nombreuses contraintes ont été soumises quant à la maintenabilité de la future solution. Nous devions notamment pouvoir intégrer des évolutions de structure aisément (structure des fichiers input et output), sans avoir à aller « se dépatouiller dans le code ».
Ces critères de pérennité et de réactivité sont d’autant plus forts que la dépendance au fournisseur est importante. En effet, que l’on choisisse un développement spécifique en interne, les services d’une société externe ou un progiciel d’un éditeur, la dépendance de la relation client-fournisseur est primordiale à prendre en compte. La question du support survient alors, de quel support pouvons-nous disposer ? Là encore c’est selon le besoin de support, qu’il faudra choisir la solution à développer.
Pour le développement de l’outil de génération de données, le choix d’un progiciel ETL open source apportait une dimension singulière au support : l’aspect communautaire.

Proposition d’une démarche à suivre

Dans le but d’apporter une réponse à notre de problématique de départ, à savoir « Quels sont les critères de décision à prendre en compte dans le choix entre développement spécifique et progiciel ? », nous souhaitons proposer une démarche à suivre quant la décision entre développement spécifique et progiciel.
Cette proposition est le fruit de l’analyse théorique et de l’analyse de terrain réalisé dans ce mémoire. Nous présentons ici, une des démarches possibles pour cette problématique.
Cette procédure se prête parfaitement à la mission réalisée au sein du service IS à Schneider Electric, elle peut également être adaptée à d’autres projets. Toutefois cette démarche n’est pas générique, elle pourra ne pas convenir selon les projets, c’est pourquoi il est primordial d’évaluer le besoin du projet en premier lieu, avant de partir dans une démarche décisionnelle.

CONCLUSION

« Conduire un projet, c’est passer d’un début où l’on peut tout faire, mais où on ne sait rien, à une fin où on n’a plus aucun degré de liberté pour exploiter toute la connaissance qu’on a acquise en cours de projet. » C. Midler
L’objectif de ce mémoire est de chercher à savoir quels sont les critères de décision à prendre en compte dans le choix entre développement spécifique et progiciel ?
Au travers de la réalisation d’un état de l’art et d’une analyse de terrain nous avons tenté d’apporter quelques éléments de réponses en proposant une démarche à suivre :
Nous avons vu qu’entre un progiciel non paramétrable et un développement 100% sur mesure se trouvait un vaste territoire de solutions.
Bien qu’il existe, plusieurs critères de décision face au choix entre une solution progiciel ou une solution spécifique, le critère indispensable à tout projet est le besoin du client. C’est à partir de ce critère que nous devons initier la démarche pour la conception et le développement d’une solution informatique adéquate.
La démarche préconisée dans le mémoire, n’est qu’une des différentes façons de procéder dans le but d’effectuer le choix entre développement spécifique et progiciel.
Elle se base sur des critères recensés dans la littérature, des études de cas et s’appuie également sur mon expérience au sein de Schneider-Electric.
Au cours de cette mission nous avons pu aborder la dimension « open source » d’une solution informatique. Cette problématique s’ajoute au dilemme qui existe entre développement spécifique et progiciel, elle se doit d’être pris en compte dans le développement d’un outil, qu’il soit spécifique ou logiciel.
Il nous paraîtrait ainsi cohérant, en complément de notre démarche décisionnelle, d’établir des règles, des critères de décision afin de nous guider dans ce choix entre développement spécifique et progiciel tout en intégrant la dimension des logiciels open source ou propriétaire.

Table des matières
Remerciements
Résumes
Table des illustrations 
Avant-Propos 
Introduction
1. Choix entre développement spécifique ou progiciel : la théorie 
1.1. Définitions
1.1.1. Notion de logiciel et développement spécifique
1.1.2. Notion de progiciel
1.2. Etudes de cas, avantages et contraintes des deux solutions
1.2.1. Etude de cas : « Faut-il développer soi-même en PME ? »
1.2.2. Etude de cas : La vision de Martin Fowler
1.3. Identification des thématiques
2. L’analyse de terrain IS, à Schneider Electric 
2.1. Le contexte de la mission
2.2. La démarche mise place
2.2.1. De l’analyse jusqu’au questionnement : développement spécifique ou progiciel ?
2.2.2. Maquettage et démarche itérative
2.2.3. Démarche en terme de management
2.2.4. Résultats
2.3. Les critères de décision et arguments recensés
3. La confrontation de la théorie et de la pratique
3.1. Analyses et comparaison des arguments théoriques et pratiques
3.1.1. Les thématiques et arguments
3.1.2. Les processus décisionnels présentés
3.2. Proposition d’une démarche à suivre
Conclusion
Bibliographie 
Annexes 

Télécharger le rapport complet