Accueil
Rechercher:
sur developpez.com sur les forums
Forums | Tutoriels | F.A.Q's | Participez | Hébergement | Contacts
Accueil Conception Java DotNET Visual Basic  C  C++ Delphi MS-Office SQL & SGBD Oracle  4D  Business Intelligence
Club Emploi Blogs   TV   Dév. Web PHP XML Python Autres 2D-3D-Jeux Sécurité Windows Linux PC Mac
LE CLUB TEMOIGNAGES NEWSLETTER REGLES PARTICIPEZ HEBERGEMENT HUMOUR CONTACTS CHAT BOUTIQUE

Faut-il développer soi-même en PME?

Par Maxence HUBICHE
 

Developpez.com a été contacté par Aurélie Chandèze, journaliste, afin de récupérer des témoignages autour du thème : "Faut-il développer soi-même en PME?"
Vous trouverez ci-aprés son article, ainsi que les commentaires qui lui ont été envoyés par l'équipe.


1. Aurélie Chandèze : Faut-il développer soi-même en PME ? (Article original)
2. Articles et Commentaires de l'équipe
2.1. Jean-Marc Rabilloud :
2.2. Gaël Donat :
2.3. Maxence Hubiche : Comment faire un choix de développement
Développer soi-même la solution ?
Faire développer ou acheter ?
Conclusion
3. Les pages du 'Monde Informatique'


1. Aurélie Chandèze : Faut-il développer soi-même en PME ? (Article original)


Quand il s'agit de mettre en place une application métier, la PME est souvent confrontée à deux possibilités, l'achat d'un progiciel ou la réalisation d'une application sur mesure. PME et développeurs font partager leurs expériences.

Quand la Mutuelle des Motards décide de moderniser son système d'information, elle s'aperçoit vite qu'aucun progiciel pour l'assurance ne répond vraiment à ses besoins. "Il a rapidement été question de refondre l'outil existant" déclare Thierry Caillard, responsable des systèmes d'information. Le métier de cette PME de 350 salariés diffère de celui des assureurs traditionnels, notamment à cause du risque élevé d'accidents corporels chez ses sociétaires. Ce type de dommages était mal pris en compte dans les progiciels du marché. La société a donc retenu une solution mixte. L'offre de Prima Solutions leur fournit plusieurs briques du nouveau système d'information. Elle permet de mettre en oeuvre facilement les règles métiers et son ouverture autorise l'ajout de développements plus spécifiques, réalisés avec l'aide de la société de services Open Wide. "L'autonomie qu'apporte 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" précise Thierry Caillard. A l'inverse, la société Rousselon, coutellerie de 50 personnes basée à Thiers, mise sur les progiciels. "Dans notre secteur, c'est une fadaise de croire qu'on ne peut trouver de progiciel bien adapté à notre entreprise", déclare Lionel Sol, directeur général. La société n'a réalisé aucun développement en interne, ne disposant ni du temps ni des moyens nécessaires. Elle gère son activité avec un ancien progiciel de gestion d'Interlogiciel, G3. Quelques développements ont tout de même été réalisés par la société DBI pour adapter la solution à leurs besoins. L'objectif de Lionel Sol reste cependant de trouver le produit qui n'oblige pas à réaliser ces développements supplémentaires.

En effet, la société a connu quelques difficultés à cause de ces ajouts en passant à une autre version du progiciel. En outre, la société Rousselon a constaté que des éditeurs comme Interlogiciel prenaient souvent en compte les modifications ajoutées par leurs clients dans leurs nouvelles versions. L'entreprise hésite cependant à renouveler le progiciel en place, espérant faire durer les investissements engagés.

Le coût réel d'une application reste en effet la principale préoccupation des entreprises, quelle que soit sa taille. "Que l'on choisisse de développer ou d'acheter un programme, on ne peut pas faire L'économie de la phase d'analyse, sinon on s'expose à voir surgir des frais imprévus", précise Catherine Charlesson, directrice informatique de Playmobil France (voir ci-dessous). Une analyse mal menée lors de l'achat d'un progiciel peut être lourde de conséquences financières pour une PME, car elle ne pourra pas faire les adaptations nécessaires par elle-même. Les évolutions futures, la maintenance ont également un coût, quel que soit le choix. Selon Catherine Charlesson, le développement en interne comporte deux grands risques pour une PME : les équipes étant très réduites, le départ d'une personne peut avoir des conséquences fatales pour une application. L'autre risque est de ne pas pouvoir suivre les évolutions technologiques "Une application qui n'évolue plus meurt doucement."

Dans leur carrière, les développeurs voient souvent les deux côtés du miroir. C'est le cas de Gaël Donat, aujourd'hui ingénieur d'études en SSII, qui a débuté chez un éditeur de progiciel puis a travaillé ensuite pour des petites structures. Selon lui, "le besoin du client est l'élément moteur dans le choix d'un progiciel ou d'un développement spécifique. Beaucoup de PME n'ont ni le temps ni les ressources suffisantes pour former leur personnel sur des progiciels souvent faits pour les grandes entreprises." Dans les PME qui ont opté pour un progiciel, Gaël Donat a souvent observé que l'utilisation réelle de l'outil concernait 5 à 20 % de ses fonctionnalités. Dans de tels cas, un développement spécifique aurait pu répondre aussi rapidement aux attentes, car il n'ajoute pas de fonctions inutiles.

Un consultant indépendant, de plus de douze ans d'expérience en développement, fait quant à lui le constat suivant : "Depuis quelques années, on voit apparaître sur le marché des progiciels de gestion allégés. Les grands éditeurs lancent des versions plus abordables de leurs solutions, qui ciblent les PME. Dans les faits, ces produits me semblent mieux adapté aux PME commerciales, dont le métier est d'acheter pour revendre, plutôt qu'aux PME industrielles, qui ont souvent des besoins très particuliers. Il n'est pas forcément justifié de faire développer une gestion de paie ou une comptabilité, en revanche une gestion de la production a souvent intérêt à être faite sur mesure." Ce consultant souligne aussi que s'il existe des progiciels pour les très petites organisations et d'autres pour les PME à partir d'une centaine de salariés, il n'y a pas grand-chose pour la taille intermédiaire.

Maxence Hubiche, développeur indépendant et membre du programme MVP (Most Valuable Professional) de Microsoft soulève une autre question importante "Que se passe-t-il si l'éditeur disparaît" Pour lui, ce n'est pas un hasard si les produits MS Access et MS Excel sont si utilisés pour développer de petites applications, tant il est peu probable que l'éditeur abandonne ces deux produits.

Plusieurs possibilités s'offrent aux PME qui ont besoin d'applications spécifiques adapter un progiciel existant, faire développer une application en externe, ou la concevoir en interne. Si la PME n'a pas les moyens d'embaucher un développeur professionnel, la dernière option peut se révéler hasardeuse. Jean-Marc Rabilloud, un développeur expérimenté qui connaît bien les petites structures, a vu beaucoup de programmes inachevés faute d'avoir été conçus par un spécialiste de la réalisation d'applications.

"La programmation par des amateurs éclairés pose souvent de gros problèmes de maintenance, les codes n'étant pas documentés voire exotiques" rappelle-t-il. Même expérience chez le consultant indépendant "Beaucoup d'applications sont réalisées par des stagiaires, des responsables marketing... Cela débouche souvent sur des programmes bancals, mais qui fonctionnent bon an, mal an, jusqu'au jour où il faut les faire évoluer." Mais si la PME dispose d'un développeur de métier, la conception en interne peut se révéler avantageuse: "Lorsqu'on externalise le développement à une société de services, toute modification du cahier des charges entraîne une augmentation du coût", rappelle Jean-Marc Rabilloud. "En outre, le développement d'une application métier est plus rapide quand le développeur connaît bien l'entreprise. Même s'il est difficile à chiffrer, ce gain de temps peut être considérable." conclut-il.

AURÉLIE CHANDÈZE,
AVEC LA COLLABORATION
DU SITE DEVELOPPEZ.COM
Retrouvez "Le monde informatique" sur le net


2. Articles et Commentaires de l'équipe



2.1. Jean-Marc Rabilloud :


De par mon expérience, je ne vais parler que de progiciels spécifiques c'est-à-dire orientés vers les métiers de l'entreprise (entreprise non informatique).

Le choix du développement interne repose en fait sur trois constats.

  • La rédaction d'un cahier des charges à destination d'une société de développement est loin d'être une sinécure. Définir clairement les besoins et le fonctionnement d'un programme est en soi difficile à réaliser. Lorsqu'on 'externalise' le développement toute modification du cahier des charges entraîne une augmentation du coût.
  • Le développement d'une application orientée métier est plus rapide lorsque le développeur connaît le métier, ainsi que les habitudes de fonctionnement de l'entreprise. Même s'il est difficile à chiffrer, ce gain de temps peut être considérable. De plus, il est plus facile de réorienter le programme au cours du développement si celui-ci est interne.
  • Les développements spécifiques sont particulièrement onéreux. Très souvent d'ailleurs hors de portée d'une PME, mais j'y reviendrais un peu plus loin.

Les problèmes du développement en interne, du moins ceux que j'ai pu constater, viennent en fait du niveau du développeur.

  • Je ne compte plus le nombre de programmes inachevés que j'ai vu, la plupart du temps car la personne chargé de son développement a cru qu'elle pourrait le réaliser. Or développer un progiciel demande de maîtriser le développement d'une application, ce qui va beaucoup plus loin que le simple codage.
  • La programmation par des amateurs éclairés pose souvent de gros problèmes de maintenance (code non documentés voire exotiques) ou de fonctionnalités. On trouve parfois des logiciels qui ne sont pas utilisés par l'entreprise quoique étant terminés car ils se révèlent impossible à utiliser.

En fait, il n'y a pas de solutions miracle. Pour une PME, le choix est relativement restreint. Il est difficile de trouver des personnes qualifiées dans les métiers de l'entreprise sachant développer de façon professionnelle. L'embauche d'un informaticien professionnel pour une petite structure n'est pas toujours viable à long terme puisqu'il est rare d'avoir des progiciels à développer suffisamment souvent pour employer une personne à plein temps. Les développements spécifiques sont souvent hors de prix.

Partant de la, de nombreuses entreprises préfèrent tenter d'adapter des logiciels existant à leurs besoins. Ce n'est souvent pas convaincant à l'usage car outre le fait que le logiciel ne correspond que partiellement au besoin, cela demande aussi un investissement important du personnel amené à utiliser ce logiciel.


2.2. Gaël Donat :


J'ai commencé à travailler chez un éditeur de progiciel comptable, puis j'ai eu à mettre en place un certain nombre d'application spécifique dans des PE, cela m'a permis de voir les deux cotés du miroir.

Tout les projets définis ont vue le jour et sont pour la plupart toujours en exploitation.

Je pense que l'élément moteur dans le choix d'un progiciel ou d'un développement spécifique réside dans les besoins du client, beaucoup de PME n'ont pas le temps ni les ressources suffisantes pour former leur personnel sur des progiciels fait la plupart du temps pour des grandes entreprises, ces progiciels sont souvent complexe, nécessitant une formation poussé des utilisateurs, et des ressources informatiques inadéquates pour une PME.

Pour donner un exemple, dans une PME, l'utilisation réel d'un progiciel par rapport a ses fonctionnalités dans son ensemble est de l'ordre de 5 à 20% suivant les cas.

A contrario, un développement spécifique permet de répondre très rapidement au attente : Adaptabilité, le projet contient exclusivement le besoin de l'entreprise, sans s'entourer d'apparat, c'est très rassurant de savoir qu'on a un interlocuteur qui écoute, qui prends nos besoins comme base de travail.

Réactivité, Toute intervention dans le projet, qu'il soit en étude ou en développement peut être effectué bien plus rapidement que dans le cadre d'une relation client-fournisseur, l'éditeur de progiciel, même si il souhaite répondre au mieux aux attentes de ses clients, il ne peut pas satisfaire toutes les demandes, tant que celles ci ne sont pas redondantes.

Portabilité, La plupart du temps, lorsque qu'un client adopte un progiciel, c'est à lui d'adapter son infrastructure en fonction des pré-requis de l'editeur, dans le cas d'un developpement spécifique, c'est exactement le contraire, c'est le developpement qui s'intégre dans l'infrastructure existante, ça aussi c'est un point rassurant pour une PME, ne pas avoir l'impression de tout changer.

Pour finir, un autre élément est à prendre en compte et pas des moindres, les coûts de developpement, suivant les projets les differences entre un progiciel et un developpement spécifique peut etre vraiment énorme, bien evidemment le cout est un facteur decisif dans le choix d'un progiciel ou d'un dev spec. , malgré cela j'ai souvent vu des PME prendre des progiciels au détriment d'une application montée en interne.

Les raisons les plus souvent évoqués etaient que l'entreprise n'avait pas de ressource en interne pour faire le developpement, ou bien l'entreprise n'avait pas envie de se lancer dans un projet et préférais prendre une solution clé en main.


2.3. Maxence Hubiche : Comment faire un choix de développement


La question du développement est un point crucial pour les PME.

Avoir des outils lui permettant d'aller de l'avant dans son activité est essentiel dans un cadre concurrentiel

Il faut allier productivité, réactivité et efficacité

Face à un besoin, les problématiques les plus souvent mises en avant sont :

  • Le coût : Peu de PME peuvent se targuer d'avoir une trésorerie luxuriante. Ce point est celui qui régit presque tous les autres, la plupart du temps
  • La dépendance : Que se passera-t-il si l'Editeur disparaît ? L'investissement sera-t-il perdu ?
  • Le support : Si j'ai un souci, quand et à quel coût (toujours ce point primordial) pourrais-je être dépanné ?
  • La technologie : Le progiciel envisagé sera-t-il obsolète, technologiquement parlant, dans quelques mois ? années ? Faudra-t-il tout refaire ?
  • Le délai : Si le besoin est urgent, sous combien de temps peut-on avoir une réponse à ce dernier ?
  • La souplesse : la mise à jour, les modifications implique-t-elle de lourds traitements ? Pourrions-nous les faire nous-même pour ne pas accroître les coûts ?

Trois solutions s'offrent alors aux entreprises :

  • Développer elle-même la solution
  • La faire développer
  • Acheter une solution existante


Développer soi-même la solution ?


Tous ces points font que, souvent, les personnels 'bidouillent' dans leur coin une application correspondant à leurs besoins immédiats, avec des logiciels accessibles déjà installés sur leurs postes, comme Excel ou Access

Ces deux produits représentent les deux premières bases de données au monde en terme de volume d'information

Il doit bien y avoir une raison à cela ! Examinons cela :

  • Le coût : Dans la plupart des entreprises, Excel, et parfois même Access sont déjà installés. Pas de surcoût au niveau logiciel donc...
  • La dépendance : Microsoft ne peut en aucun cas abandonner ces produits, l'investissement est donc sauf.
  • Le support : C'est l'utilisateur qui a développé son application. Ces produits sont accessibles à la plupart des utilisateurs.
  • La technologie : Les produits suivent les avancés technologiques. On ne perd pas sont travail.
  • Le délai : La souplesse de ces outils permet à l'utilisateur de développer son outil à son rythme.
  • La souplesse : c'est leur grande force !

Rares sont les PME qui se lancent dans de grands développements et qui les mènent à termes avec leurs uniques ressources internes. Ils est souvent peu aisé d'avoir des personnes qui soient efficaces aussi bien dans l'analyse que dans l'architecture que dans la sécurité que dans . chacun des aspects que l'on peut rencontrer dans le cadre du développement. Ce sont donc souvent les outils bureautiques qui sont utilisés comme autant de rustines aux manques de l'informatique interne

Quoiqu'il en soit, ce genre de solution ne fait souvent de décaler les problèmes originaux

  • Le coût : L'investissement en temps du ou des personnels concernés est rarement analysé. Or souvent, les utilisateurs passent un temps important sur la réalisation de leur solution. Et comme chacun le sait, le temps, c'est de l'argent
  • La dépendance : Je n'ai pas en souvenir d'avoir vu un code développé par des personnels de PME qui ait été correctement commenté. Si l'employé responsable du projet vient à quitter la société, il est souvent le seul à connaître les méandres de son programme. Qui va reprendre derrière ?
  • Le support : Il reste le bouche à oreilles pour se sortir de situations usuelles. Mais qu'en est-il s'il y a un vrai problème de fond qui surgit ? L'employé en question n'est plus là
  • La technologie : Parfois, les versions évoluant, de petites mises à jours sont à faire. qui va les faire ?
  • Le délai : Reprendre un programme non documenté , afin d'y ajouter des fonctionnalités est certainement le travail le plus rébarbatif qui soit. Il faut intégrer les règles métier implémentées dans le progiciel. Comprendre ce qu'à voulu faire le développeur de l'application, décortiquer le code, . cela allonge les interventions à venir.
  • La souplesse : Au moins, cela reste. Si la solution était souple au départ, elle le restera par la suite, à moins que les besoins aient tellement grossis que les outils soient sous dimensionnés, auquel cas, une refonte totale du progiciel serait à envisager.

On peut donc en conclure que, pour un besoin immédiat, la solution peut sembler intéressante. Cependant de nombreux pièges se profilent à l'horizon. Il faut savoir les analyser. Il faut savoir les prévenir. Cela n'est pas aisé


Faire développer ou acheter ?


Parfois, cependant, les solutions à mettre en ouvre dépassent le stade de la bureautique, ou de la petite informatique.

Il faudrait envisager la mise en place de solutions Internet, de serveurs, .Dans ces cas-là, les mêmes problèmes se reposent, mais à une échelle plus importante

Il convient donc de se poser une série de questions :

  • Le progiciel répondant à la demande existe-t-il dans le commerce ?
  • Si oui, répond-il intégralement aux besoins ? Quel est son Coût ? Quels coûts induisent l'acquisition des compléments nécessaires ?
  • Si non ais-je les compétences en interne, ou faut-il faire développer ?

La comparaison entre le coût d'une solution développée et d'une autre achetée est souvent difficile.

Il faut mettre dans la balance le coût, mais les pondérer par l'adéquation entre le besoin et la solution.

Un produit développé, peut-être un peu plus cher, mais répondant parfaitement, de manière absolue, au besoin ne permettra-t-il pas un gain en performances, en qualité de travail ?

Dans le cas d'un développement externe, en tant que client, la PME a le droit de négocier, et est donc susceptible d'obtenir une réponse positive à toutes ses demandes.

Il conviendra donc de veiller à demander :

  • l'utilisation de technologies faciles à mettre en ouvre et à maintenir par une majorité de personnes (souvent autour des technologies Microsoft largement représentées dans les entreprises)
  • la récupération du cahier des charges
  • la récupération des sources du programme
  • la récupération de la documentation technique du produit
  • la récupération de la documentation utilisateurs du produit

Ainsi, elle reste maître de sa solution. En cas de souci avec le prestataire, elle est susceptible de faire appel à n'importe quel autre prestataire pour reprendre le flambeau


Conclusion


Le processus décisionnel est, dans les grandes lignes, celui-ci :

Hormis les solutions Abandon et Achat, chaque cas est à examiner de manière approfondie, afin d'éviter les écueils et de rester toujours en phase avec les critères initialements retenus dans les domaines des coûts, dépendances, support, technologie, délai et souplesse.


3. Les pages du 'Monde Informatique'


Avec l'aimable autorisation du journal 'Le Monde Informatique', retrouvez cidessous les reproductions des deux pages concernées :




Mes tutoriels :
(23/10/04) La notion de Classe de Formulaire Access
(21/08/04) Access - Les Bases : Introduction et Conception
(20/08/04) Fermer automatiquement une base Access
(28/03/04) Comprendre les jointures / Relations dans Access
Mes articles :
(21/06/04) Faut-il Développer en PME (Le Monde Informatique)
(15/03/04) Les Nouveautés Access 2003
Mes sites :
Sur access-maxence
Mon blog
Case Studio (Logiciel de modélisation de données)
En cours de production :
Access - Les Bases : Suite et Fin
Tutoriel sur les Sous-Formulaires
En Projet :
Listing explicatif des fonctions d'Access
Access - Perfectionnement : Exploitation des données
Access - Expert : Interface et automatisation
Access - VBA
Access - VBA : Perfectionnement


Ce document est et reste la propriété exclusive de ses auteurs.
La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation des auteurs.

Responsable bénévole de la rubrique Club : Yann D'Isanto - Contacter par EMail :
Vos questions techniques : forum d'entraide Club - Publiez vos articles, tutoriels et cours
et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones
Nous contacter - Copyright © 2000-2008 www.developpez.com - Legal informations.