Comment bien choisir un logiciel d’entreprise ?

Si vous êtes entrepreneur, gestionnaire de projet, responsable informatique ou peut-être tout ça à la fois, pour répondre aux besoins de votre entreprise vous avez sans doute déjà eu à faire un choix entre plusieurs solutions logicielles.

Vous savez donc que c’est une décision qui soulève pas mal de questions :

• Comment identifier les solutions qui conviennent, et comment les comparer ?
• Quelle différence entre un CMS, un ERP, un CRM, un HRS ?
• Dois-je m’orienter vers une solution existante ou vers du développement sur mesure ?
• Quel éditeur, quel framework, quel langage ?
• A quels éléments techniques faut-il être attentif ?
• Quelles technologies, quel type d’infrastructure, quels sont les aspects UX/UI les plus importants ?

Bref, comment choisir ?

Aujourd’hui je vous propose donc de découvrir les clés qui vous permettront de répondre par vous-mêmes à toutes ces questions !

Pour quoi faire ?

En tant qu’êtres rationnels, quand nous devons faire un choix, notre réflexe est systématiquement de sélectionner l’outil qui semble à la fois le plus adapté à nos besoins immédiats et qui offre le plus d’avantages.

Du coup, lorsqu’il s’agit d’un outil logiciel, choisir une solution offrant une large gamme de fonctionnalités (et même plus que celles dont on a réellement besoin) semble être la bonne approche. Logique : même si nos besoins évoluent, plus la solution offre de fonctionnalités, plus il y a de chances qu’elle prennent en charge les besoins futurs.

Il y a deux problèmes à cette approche:

• le premier, c’est que, comme je le présenterai dans un instant, rechercher l’outil idéal parmi les solutions existantes est loin d’être simple !
• le second problème c’est que les technologies, les habitudes et les besoins qui en découlent évoluent de plus en plus vite, et de manière difficilement prévisible (Par exemple, au début des années 2000 on pouvait se demander s’il valait mieux choisir un logiciel tournant sous Windows, sous Mac OS ou sous Linux : aujourd’hui cette question n’a plus de sens : la majorité des solutions fonctionnent sur le Cloud et sont accessibles avec un navigateur ou une App tournant sur iOS ou Android)

En fait, la meilleure approche consiste avant tout à déterminer le rôle de l’outil que vous recherchez; comment il sera utilisé; et quelle importance il aura par rapport à votre business ou à votre cœur de métier.

S’il s’agit d’une application que vous utiliserez tout le temps et dont vous ne pourrez pas vous passer, faire un mauvais choix non seulement risque de vous pénaliser au quotidien (personnalisations difficiles, manque d’ergonomie, mises à jour complexes, incompatibilité avec d’autres logiciels) mais également de vous rendre captif de cette solution ce qui vous mettrait dans une situation de laquelle vous auriez du mal à vous sortir.

En amont de toute décision, les bonnes questions à se poser sont donc :

• quelle est la fréquence des besoins ?
• quelle est la durée prévisionnelle d’utilisation ?
• combien de personnes sont concernées par l’utilisation de la solution recherchée ?

Si la solution recherchée est destinée à répondre à des besoins ponctuels ou pour une courte durée, ou à être utilisée par peu de collaborateurs, alors et foncez vers ce qui semble le mieux adapté à vos besoins immédiats pour le coût le plus bas possible (en n’oubliant pas de prendre en compte les coûts récurrents : licences, abonnements, support). Il peut tout aussi bien s’agir d’une solution existante que d’une solution développée sur mesure en RAD. Dans ce type de situation, l’outil peut être considéré comme une solution jetable : l’idée est d’avoir quelque chose d’opérationnel rapidement, qui soit amorti en peu de temps et qui sera éventuellement remplacé si et quand le besoin s’en fera sentir.

Si par contre, la solution est destinée à répondre à des besoins réguliers ou permanents et à être utilisée par un grand nombre de collaborateurs, alors il est crucial que la solution retenue réponde à des critères garantissant que vous pourrez faire évoluer la solution selon vos besoins ou, au minimum, migrer aisément le moment venu vers une autre solution plus complète.

Solution existante ou Développement sur mesure ?

Evidemment, il est facile de succomber aux charmes du mythe de la solution toute faite – clé sur porte – qui répond à tous nos besoins !

Le problème, c’est que nous sommes définitivement entrés dans l’ère digitale : il y a de plus en plus de nouveaux métiers basés sur ou dépendant du digital, de plus en plus de types de flux de données et de plus en plus de solutions logicielles pour répondre aux nouveaux besoins.

Rien que pour les applications à destination des entreprises, le site datanyze recense près de 10.000 solutions logicielles.

L’application qui répond parfaitement à vos besoins, si elle existe, sera sans aucun doute très difficile à trouver.

Par exemple, beaucoup de solutions se recoupent dans le sens où elles présentent certaines fonctionnalités en commun mais avec des variations en termes d’interface utilisateur, de support de solutions ou de formats, ou encore de fonctionnalités annexes. Pas facile dans ce cas d’y voir clair et les critères de comparaison entre plusieurs solutions peuvent rapidement devenir confus, voire subjectifs.

Se baser uniquement sur la réputation est également risqué : de nombreuses solutions mettent en avant des fonctionnalités phares qui ont fait leur force et avec lesquelles elles attirent de nouveaux clients, mais rien ne garanti que la stratégie commerciale de l’éditeur n’est pas de rendre les clients captifs ni que la solution pourra évoluer en fonction des nouvelles tendances technologiques ou des nouveaux besoins des clients.

Il existe aussi des solutions qui se présentent sous la forme d’une base de fonctionnalités (« foundation ») offrant la possibilité d’intégrer une collection de modules, plugins, addons ou packages. Ces modules pouvant être développés et publiés par le même éditeur; par des fournisseurs externes; par des agences de développement spécialisées; ou même par l’utilisateur final lui-même (être entrepreneur implique souvent de savoir faire beaucoup de choses ;-).

Cependant, avec un peu expérience, on se rend compte que ces logiciels de type « Fondation Applicatives » ont quelques inconvénients:

• ils sont complexes, impliquent un délai conséquent pour être maitrisées, nécessitent généralement des développeurs avec une expérience spécifique … et un tarif horaire plus élevé;
• ils impliquent parfois une infrastructure avec des ressources conséquentes ou un processus d’installation et de configuration complexe;
• le tarif du service de support est élevé et s’accompagne généralement d’une licence annuelle ou mensuelle basée sur le nombre d’utilisateurs;
• dans de nombreux cas, seule une petite partie des fonctionnalités est réellement utilisée;

Par ailleurs, il est assez courant pour une entreprise de distribuer ses process sur des infrastructures distinctes (pour des raisons organisationnelles, de sécurité, ou pour se conformer aux compétences spécifique de chaque département) et de devoir ensuite les faire communiquer, ce qui annule la plupart des avantages d’avoir une solution tout-en-un;

De plus, entre le moment de l’acquisition et celui auquel on aura effectivement l’usage des autres fonctionnalités disponibles, il est probable que la solution nécessite une mise à jour (sans garantir que les customisations restent supportées); ou il se peut qu’une autre solution, mieux adaptée, soit alors disponible; ou on peut même imaginer que l’entreprise ait fusionné avec une autre et que solution doivent être adaptée à un autre logiciel ou d’autres standards.

C’est pourquoi si la philosophie agile recommande la mise en œuvre à partir de fondations solides, elle préconise également avant tout de se concentrer sur les besoins immédiats.

Bien entendu, il y a de nombreuses façon d’utiliser et d’intégrer un logiciel, mais l’assertion suivante se vérifie toujours : « plus une solution est évoluée, plus elle est complexe à adapter ».

Enfin, selon le contexte, des « fondations solides » peuvent très bien être un framework applicatif utilisant un langage de programmation standard.

Si le projet implique simplement une sélection de modules existants et de la configuration, l’avantage va incontestablement aux Fondations Applicatives.

Par contre, si vous recherchez quelque chose qui s’adapte à des caractéristiques spécifiques qui sont propres à votre business, posez-vous les deux questions suivantes :

• De quelle portion de la solution considérée ai-je réellement besoin ?
• Quels part de mes besoins sont couverts par la solution ?

Si les deux réponses sont des valeurs faibles alors, il sera souvent plus intéressant de se limiter aux besoins immédiats et de faire développer une solution sur mesure pour un budget final moindre et dans un délai plus court.

A quels aspects être attentif ?

Si le besoin correspond à une solution destinée à occuper une place importante pour votre business, son degré d’évolutivité; la possibilité de la connecter à d’autres solutions; ou éventuellement sa capacité à être interfaçée, auront potentiellement un impact considérable sur votre business.

Il est donc important de connaître les critères qui permettent de déterminer le degré d’évolutivité d’une solution afin de pouvoir identifier les solutions qui sont à éviter.

Bien sûr, la maîtrise des technologies impliquées dans les solutions envisagées sort probablement de votre domaine de compétences et vous déléguez (ou envisagez de déléguer) les aspects techniques à un partenaire ou à une équipe de professionnels.

S’il s’agit de choisir parmi des solutions logicielles existantes, certaines solutions laissent peu de marge de manoeuvre et impliquent nécessairement l’utilisation de technologies spécifiques. A l’opposé, si on s’oriente vers un développement sur mesure, le partenaire aura beaucoup plus de latitude dans le choix des technologies.

Dans tous les cas, quel que soit le partenaire qui prendra en charge le développement, il aura certainement une solution ou une pile logicielle de prédilection et il vous faudra un minimum de connaissances pour vous permettre de valider ses choix.

Concepts impliqués

Pour établir les critères d’évaluation d’une solution, il suffit de comprendre 3 concepts de base.

1. Pile logicielle

Une solution logicielle dépend toujours d’un empilement de couches :

De la couche la plus haute, qui permet les interactions avec l’utilisateur, à la couche la plus basse, dédiée au stockage physique des données.

Chaque solution dispose de sa propre pile de dépendances, mais la plupart des solutions modernes s’articulent de la manière suivante:

• interface utilisateur
• framework
• langage de programmation
• moteur de base de données
• serveur web
• OS

Parmi les piles logicielles ou « Tech Stack » populaires, on peut citer :

LAMP: Linux, Apache, MySQL, PHP MEAN: MongoDB, Express.js, Angular, Node.JS MERN: MongoDB, Express.js, React, Node.JS LNMP: Linux, Nginx, MariaDB, Python

S’il faut s’intéresser à la pile logicielle, c’est parce que la vitesse à laquelle les technologies et les outils évoluent dépend de la couche à laquelle on se réfère.

Plus la couche est basse dans la pile applicative, moins elle est volatile. Par exemple: la logique du système de fichiers Linux, utilisé par l’écrasante majorité des serveurs, est basée sur l’utilisation d’inodes. En près de 30 ans il y a eu seulement 4 versions du « ext File System »; alors que dans le même temps, la couche de présentation graphique « Gnome » a connu plus de 40 versions (https://fr.wikipedia.org/wiki/GNOME), c’est-à-dire des changements 10x plus rapides.

Face à ce constat, on peut en déduire que l’importance de l’évolutivité d’une dépendance faisant partie d’une pile logicielle est inversément proportionnelle à sa hauteur au sein de cette pile.

Dit autrement: quelle que soit la solution logicielle, il sera (presque) toujours plus rapidement nécessaire de faire des mises à jour des éléments du haut de sa Tech stack, que de ses éléments du bas.

2. Front-end & Back-end

Finalement, une application peut se résumer à un ensemble d’instructions qui manipulent des données selon une certaine logique.

Au sein de ces instructions, on peut faire une distinction entre celles liées aux interactions avec l’utilisateur et celles qui servent à la manipulation des données conformément à la finalité de l’application.

On regroupe sous le nom de Front-End tout ce qui a trait aux interactions avec l’utilisateur. Comme par exemple la gestion des événements de type clic sur un bouton ou drag-n-drop, l’affichage de données sous forme de liste ou d’arborescence, de calendrier ou d’objets sur une carte.

Par opposition, le Back-End correspond aux instructions liées à la finalité de l’application. Par exemple les algorithmes décrivant la manière de produire certains résultats, la conversion de données en différents formats, ou encore le transfert de données.

3. Logique métier

Dans le cas d’une solution applicative pour entreprise, la finalité de l’application est de correspondre au fonctionnement de l’entreprise. On parle également de logique métier.

Par exemple: traiter des documents selon un workflow déterminé, retrouver les informations liées à un client selon certains critères, calculer le prix de vente en fonction des taux de TVA applicables, ou encore faire des envois d’emails automatisés.

Critères

Maintenant que vous connaissez les notions impliquées, 4 critères seulement devraient vous permette d’établir une grille de comparaison relativement objective entre différentes solutions.

1. Popularité & Standards

Puisqu’il s’agit d’une solution qui sera utilisée durant une période relativement longue, il faut envisager le risque que le prestataire (personne morale ou physique) qui aura implémenté la solution ne soit plus disponible lorsque des modifications seront nécessaires.

Dans cette perspective, même s’ils ne sont pas des gages de qualité en soi, pour une solution donnée, le respect des standards techniques ou le fait de jouir d’une certaine popularité accroissent les chances trouver un autre prestataire disposant des compétences pour en reprendre le support.

2. Séparation Front-End & Back-End

Comme il est destiné à interagir avec l’utilisateur, le Front-End est toujours plus élevé dans la pile applicative. On observe effectivement que les interactions doivent pouvoir se faire avec une variété croissante d’appareils : Desktop, PC portable, tablette, smartphone, smartwatch.

Donc une solution n’ayant pas une bonne séparation entre le front-end et le back-end présente dès le départ une évolutivité réduite.

En plus, de toute évidence, moins il y aura de logique métier dans le Front-End, plus il sera facile de remplacer ou de diversifier celui-ci. Il est donc préférable que la logique métier soit concentrée au niveau du back-end.

3. Front-End

Pour le moment, c’est clairement le contexte Web qui domine le marché. Mais il se peut que vos besoins applicatifs s’inscrivent dans un contexte différent. Par exemple, s’il s’agit d’une application destinée à manipuler des données sécurisées, uniquement accessible physiquement depuis certains ordinateurs avec une configuration logicielle particulière, alors une interface Front-End reposant sur d’autres technologies (fenêtrage Win, GTK, Swing, ou autre) peut parfaitement être pertinente.

La plupart du temps, le choix de la technologie utilisée pour le front-end n’est pas un critère discriminant. Encore une fois, si la distinction FE-BE est bien réalisée, il sera toujours possible d’y remédier plus tard en cas de besoin !

Dans tous les cas, les aspects génériques auxquels accorder de l’attention sont, par ordre d’importance :

• l’ergonomie et la convivialité de l’interface utilisateur
• l’adaptabilité: c’est-à-dire la capacité à s’adapter à une large variété de formats d’écrans (lorsque le HTML/CSS est impliqué, on parle de design « Responsive »)
• la portabilité: c’est-à-dire écrit de manière à permettre la réutilisation ou, encore mieux, utilisant du code multi-plateforme. Par exemple, l’outil open source Ionic permet de « transpiler » du code écrit avec certains frameworks javascript (comme Angular, React ou Vue) pour produire du code fonctionnant aussi bien dans un navigateur que sur les appareils Android ou iOS, ou même comme Desktop App.

4. Back-End & Approche applicative

Pour les raisons que je viens d’évoquer, même s’il existe encore des solutions qui ne la suive pas, la distinction entre Front-End et back-End est désormais l’approche la plus courante, et c’est pour moi un critère excluant.

Ceci dit, il y a plusieurs façons de mettre ce paradigme en œuvre et la manière dont est conçu le Back-End est également un facteur influençant l’évolutivité d’une solution.

On peut distinguer 3 grandes familles d’approches pour cette mise en oeuvre:

Approche « solution »

• L’application se présente comme un bloc applicatif tout-en-un;
• Il y a une séparation entre le front-end et le back-end, sans toutefois y avoir nécessairement une indépendance stricte;
• Un système permet éventuellement d’interroger l’application, mais pas nécessairement dans un langage suffisamment standard pour permettre les connections directes avec d’autres outils ou plateformes, et il peut nécessiter des connecteurs spécifiques;
• Il est éventuellement possible d’intégrer des modules, ce qui est clairement un plus. Dans ce cas, il faut vérifier que des acteurs indépendant de l’éditeur du logiciel ont effectivement la possibilité de développer de tels modules (d’un point de vue technique et d’un point de vue légal – en fonction des licences);
• Une définition des permissions et des rôles est offerte, mais peut impliquer de passer par l’interface utilisateur native de la solution.

Lorsqu’on est confronté à une solution applicative de ce type, les questions à se poser sont :

• Le front-end peut-il être remplacé ou personnalisé ? Si oui, quel effort cela nécessite-t-il ?
• Est-il possible de réaliser des opérations sans utiliser l’interface graphique native de la solution ?
• Existe-t-il des connecteurs permettant de connecter cette solution à d’autres outils ?
  • la solution s’intègre-t-elle nativement avec des services externes reconnus (emailing, partage de documents, service de livraison, service réservation) ?
  • est-il possible de développer des connecteurs additionnels ?
• Est-il possible de développer des modules sur mesure ?
  • si oui, y a-t-il des limitations en termes de licences ?

Approche API

On parle d’approche de type API lorsque la solution dispose d’une interface applicative offrant un support complet, c’est-à-dire qui donne accès à toutes les fonctionnalités disponibles : lister et rechercher des objets; créer, mettre à jour et supprimer des objets; et exécuter tous les types d’actions requis par la logique métier.

Dans cette approche, la logique est organisée en micro-services, qu’il est possible d’invoquer à l’aide de contrôleurs connectés à une interface de programmation applicative ou API, qui peut être invoquée depuis n’importe quel front-end (graphique, en ligne de commande, ou programmatique).

Au niveau du back-end, la découpe en micro-services augmente la lisibilité de la logique applicative et rend le code plus évolutif : en cas de nouveaux besoins, il est possible de mettre à jour l’application en ne modifiant que le ou les micro-services concernés.

• Le modèle API peut être mise en oeuvre indépendamment du type de connexion (RPC, REST, SOAP)
• Utiliser un protocole web (HTTP) est un atout (le protocole HTTP est très largement répandu au niveau du Web et il s’agit d’une couche basse dans la pile applicative, donc qui évolue lentement)
• Utiliser un format d’échange standard comme XML, YAML ou JSON est un atout (JSON étant à préférer si le front-end est basé sur du javascript)

D’après moi, disposer d’une API offrant un support complet, est la meilleure séparation possible entre FE et BE, et est une excellente garantie d’évolutivité.

Approche distribuée

Enfin, il y a l’approche distribuée qui est une approche hybride.

Il arrive qu’une solution doive s’intégrer à un « éco-système » applicatif existant à laquelle elle ne se substitue pas (ou pas entièrement). Cette approche offre alors un très bon compromis.

Donc, même si ce n’est pas immédiatement envisagé, il est intéressant de valider si une solution envisagée permet cette approche, c’est à dire de vérifier si oui ou non elle dispose d’une API (quelle qu’en soit la forme), qui permette d’interagir avec les données à partir d’autres logiciels, et quelle part des opérations est couverte par cette API.

Conclusion

En guise de conclusion et pour résumer, lorsque vous aurez à choisir une solution posez vous d’abord les questions suivantes:

• à quoi la solution est-elle destinée ?
• qui sera amené à l’utiliser ?
• et pour combien de temps ?

Et si vous pouvez anticiper que vous en serez fort dépendant, soyez extrêmement attentif à son évolutivité pour pouvoir faire face aux tendances actuelles :

1. la durée de vie des applications diminue
2. les logiciels évoluent rapidement
3. Il y a BEAUCOUP de solutions existantes
4. le futur des technologies est incertain