I. 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'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" précise Thierry Caillard. À 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és 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

II. Articles et commentaires de l'équipe

II-A. 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 reviendrai 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 vus, la plupart du temps car la personne chargée 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é, voire exotique) ou de fonctionnalités. On trouve parfois des logiciels qui ne sont pas utilisés par l'entreprise quoiqu'étant terminés, car ils se révèlent impossibles à utiliser.

En fait, il n'y a pas de solution 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 là, de nombreuses entreprises préfèrent tenter d'adapter des logiciels existants à 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.

II-B. Gaël Donat :

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

Tous les projets définis ont vu 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 faits la plupart du temps pour de grandes entreprises, ces progiciels sont souvent complexes, nécessitant une formation poussée des utilisateurs, et des ressources informatiques inadéquates pour une PME.

Pour donner un exemple, dans une PME, l'utilisation réelle d'un progiciel par rapport à 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 aux attentes :

  • 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 prend 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ée bien plus rapidement que dans le cadre d'une relation client-fournisseur, l'éditeur de progiciel, même s'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'éditeur, dans le cas d'un développement spécifique, c'est exactement le contraire, c'est le développement 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 développement, suivant les projets les différences entre un progiciel et un développement spécifique peut être vraiment énorme, bien évidemment le coût est un facteur décisif 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ées étaient que l'entreprise n'avait pas de ressources en interne pour faire le développement, ou bien l'entreprise n'avait pas envie de se lancer dans un projet et préférait prendre une solution clé en main.

II-C. 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'éditeur 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 impliquent-elles de lourds traitements ? Pourrions-nous les faire nous-mêmes 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.

II-C-1. 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 termes 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ées technologiques. On ne perd pas son 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 à terme avec leurs uniques ressources internes. Il est souvent peu aisé d'avoir des personnes qui sont 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.

Quoi qu'il en soit, ce genre de solution ne fait souvent que 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-à-oreille 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 à jour 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'a 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 grossi 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é.

II-C-2. Faire développer ou acheter ?

Parfois, cependant, les solutions à mettre en œuvre 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 induit l'acquisition des compléments nécessaires ? ;
  • sinon ai-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 œuvre 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.

II-C-3. Conclusion

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

Image non disponible

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 initialement retenus dans les domaines des coûts, dépendances, support, technologie, délais et souplesse.

III. Les pages du « Monde Informatique »

Avec l'aimable autorisation du journal « Le Monde Informatique », retrouvez ci-dessous les reproductions des deux pages concernées :

Image non disponible
Image non disponible