Dans un autre article, nous avons parlé de la mise en œuvre des logiciels et vous avons demandé si votre entreprise s'appuie sur des solutions standard pour ses achats. Nous sommes maintenant confrontés à la question suivante : devons-nous renoncer à la personnalisation avec des solutions standard ? Et : Qu'entendons-nous par "logiciel configurable" ?

Logiciel standard : plusieurs termes - un principe

Commençons par le début. Nous décidons d'acheter une solution dite standard. Qu'est-ce que c'est, d'ailleurs ? Il y a forcément des opinions différentes sur ce point, tout comme il y a des termes différents, tels que logiciel prêt à l'emploi ou logiciel commercial sur étagère (COTS). Nous définissons ici un logiciel standard principalement en référence à la manière dont le logiciel est développé et maintenu par le fournisseur.

Le développement d'un logiciel standard suit un chemin unique sans aucun embranchement . Sur ce chemin de développement principal - également appelé tronc - des versions sont ensuite créées de manière séquentielle, qui contiennent toujours de nouvelles fonctions (également appelées fonctionnalités). De cette façon, la solution standard continue d'évoluer au fil du temps. Cela garantit également qu'une version antérieure du logiciel peut être facilement mise à jour vers une version plus récente à tout moment. C'est ce qu'on appelle la capacité de libération du logiciel, un point très critique de la configurabilité, sur lequel nous reviendrons plus loin.

La stratégie de développement est cruciale

Différents clients ou utilisateurs du logiciel peuvent donc avoir le même logiciel standard mais avec des statuts de version différents. Dans le cas d'un logiciel standard, il n'existe à aucun moment des versions parallèles issues d'une version antérieure commune (c'est-à-dire des branches) et qui couvrent des besoins différents des clients. Pour être précis : ces versions parallèles n'existent pas "en externe", c'est-à-dire vers le marché. En interne, le développement peut avoir différentes branches afin que différentes équipes puissent travailler sur différentes parties du logiciel en parallèle. Ces branches de développement sont ensuite simplement fusionnées dans une version commerciale au moment opportun. C'est ce qu'on appelle la fusion.

La stratégie de développement du fournisseur devrait désormais consister (du moins à notre avis) à concilier autant que possible tous les besoins différents des divers clients en trouvant des solutions génériques. Ces solutions d'application générale peuvent ensuite être configurées en fonction du client, afin de tenir compte de sa situation spécifique. C'est ici que nous rencontrons pour la première fois le terme "configurable".

Avec une telle stratégie de développement, des compromis doivent bien sûr être trouvés dans certaines situations, par exemple en ne mettant délibérément en œuvre qu'une seule variante de solution parmi plusieurs pour un seul et même besoin du client, qui peut alors ne pas être configuré du tout ou seulement de manière limitée. Dans ce cas, le fournisseur de logiciels doit accepter qu'il ne sera pas en mesure de satisfaire tous les clients afin de poursuivre sa stratégie de manière cohérente. Tous les clients bénéficieront alors de ces avantages. Nous y reviendrons à la fin de cet article.

La configurabilité se trouve dans la base de données, pas dans le code source.

Venons-en maintenant au concept central de ce texte : Configurabilité. D'autres parlent également ici de paramétrage ou de termes similaires. La configurabilité d'une solution standard peut être expliquée comme suit.

Dans le cas d'une application commerciale avec une architecture commune à trois niveaux, une installation logicielle typique se compose d'un serveur d'applications (niveau intermédiaire) et d'un serveur de base de données (niveau inférieur). L'utilisateur accède au serveur d'application via un client (niveau supérieur, dans le cas d'une application web, il s'agit du navigateur). Par installation, il est maintenant possible de stocker dans la base de données du système des paramètres(valeurs de configuration) qui contrôlent le comportement du système. Cependant, le serveur d'application est basé sur une version spécifique. Néanmoins, les utilisateurs remarquent des fonctionnalités ou des comportements différents du système, selon la façon dont celui-ci est configuré.

Le point crucial est le suivant : les valeurs de configuration mentionnées se trouvent dans la base de données (tout au plus dans les fichiers de configuration du serveur d'applications), mais jamais dans le code source du serveur d'applications. La configuration réelle n'a donc rien à voir avec un développement ou une adaptation du code source spécifique au client. Il en résulterait des embranchements désagréables, qui mettraient alors en péril, voire rendraient impossible, la capacité de libération. C'est précisément ce qui rend les développements ultérieurs coûteux pour le client, car ils doivent être réalisés séparément pour chaque client et le client individuel ne peut pas profiter d'un développement ultérieur global pour tous les clients.

La configurabilité ne signifie donc pas, notamment, que les adaptations se font par programmation du code source. L'adaptation du code source se fait toujours et exclusivement par le biais du développement générique des fonctionnalités de base du logiciel standard et conduit à une nouvelle version. Les configurations existantes peuvent simplement être adoptées dans la nouvelle version. Il s'agit de la capacité de libération de systèmes logiciels standard configurables ou déjà configurés.

Comment reconnaître un logiciel configurable ?

Il n'est pas si facile de répondre à cette question d'un point de vue extérieur, c'est-à-dire du point de vue du client qui souhaite évaluer et acheter un tel logiciel. Du point de vue interne du développeur, c'est bien sûr facile. Mais au cours du processus de vente, le client peut se voir présenter comme "configurable" un logiciel qui n'est en fait pas du tout configurable (au sens défini ci-dessus) et qui ne mérite pas du tout cette étiquette.

Une telle solution peut être qualifiée à juste titre de logiciel standard, car elle est développée selon une seule voie de publication. Mais il n'a pas été construit dès le départ avec une stratégie de développement qui met en œuvre des fonctionnalités de manière générique et les rend adaptables par configuration. La "configurabilité" de ces systèmes est ensuite mise en œuvre de manière efficace grâce à un développement ultérieur. Bien sûr, cela n'est pas vendu au client de cette manière.

Voici quelques caractéristiques simples d'un logiciel (réellement) configurable:

• Une configuration spécifique au client est rentable car elle implique peu d'efforts de mise en œuvre pour le fournisseur.
• La configuration peut être mise en œuvre rapidement en termes de temps (avec la même justification).
• Le système reste toujours prêt à être mis en service, c'est-à-dire que les mises à niveau vers les futures versions ne coûtent rien, ni argent ni effort.

Dans le cas de PQFORCE, par exemple, une configuration client (de l'ensemble du système, attention) représente un effort approximatif de ½ à 2 jours, selon les souhaits spécifiques et l'étendue des détails. Et lorsque nous proposons une nouvelle version, elle peut être facilement installée pour chaque client sans aucun effort.

sondage/110626]

Les avantages des logiciels standard configurables à partir du cloud computing

Enfin, nous souhaitons énumérer les avantages les plus importants des logiciels standard configurables à partir du cloud par rapport aux logiciels individuels. Des logiciels comme PQFORCE...

• ...est nettement moins cher à l'achat. Et nous ne parlons pas de pourcentages ici, mais de facteurs. Tout simplement parce qu'aucun projet de développement coûteux ne doit être financé. Et la configurabilité permet même une adaptation spécifique au client à un coût extrêmement faible - pour tous les clients qui ne veulent pas se contenter de la solution toute faite.
• ...est prêt à être utilisé très rapidement après l'achat. La configuration d'un client PQFORCE prend quelques minutes (sic !), et l'opération pilote peut donc commencer immédiatement. Dans ce cas, le degré de préparation de l'organisation du client est plutôt le facteur de freinage.
• ...permet d'utiliser des économies d'échelle. Le développement futur est piloté(crowdsourcing) et financé(crowdfunding) par un portefeuille de clients complet.
• ...propose des innovations régulières (features releases) en cycles courts de quelques semaines, qui peuvent être initiées par les clients et utilisées immédiatement dès qu'elles sont disponibles(principe DevOps).

Il n'est donc pas étonnant qu'aujourd'hui, la tendance s'oriente clairement vers les logiciels standard basés sur le cloud. Si le tout est également très bien configurable, le client a tous les atouts de son côté.